不要用无意义的努力，去赚取300%的工资

本年度先进员工的获奖者

准备五一加班的人

奖励

300%的工资+三餐补贴+按摩+免费健身

即时到账

看到这个公告，五一没有安排/单身/背负房贷/渴望晋升/期待领导赏识的你，是不是已经打算放弃五一假期，努力加班了？

如果我们告诉你，你如果打算这么做，打算用这样的努力来赢取未来，可能你离34岁后“被离职”就不远了。

你可能会反驳：“我这么努力，老板一定能看在眼里！我为公司付出这么多，每天忙得像一个陀螺，老板怎么会将我这样的人放弃？！

事实上，你内心中认为的：努力的工作-->业务熟练-->领导赏识-->步步高升-->迎娶白富美、当上CEO、走上人生巅峰，在现实生活中很有可能是：努力的工作-->熟练特定工作-->工作视野狭窄、难以变通-->失去和老板谈判的筹码-->收入/付出比例下降-->人到中年，为了生活只能进一步超时工作-->更加难以变通-->最后拿苦劳博取老板的同情。

有个老板曾经这样说过：我是一个老板，我很看重我手下的兄弟，我也会被他们感动。你要我夸奖你，没问题。但，如果你要我为这份感动买单，对不起，我先得想想，你到底给我创造了多少价值，因为我还有一大帮兄弟要养活！

你不相信？那去看看之前那些34岁之后可能被裁员的R&D人的焦虑。

什么叫做低质量、无意义的努力？低质量、无意义的努力意味着：

一个人的大脑始终依靠经验与惯性运转，没有停下来思考、升级自己认知的努力；

意味着在超时工作的身心俱疲之下，我们满脑子只想着“完成”一件事情，而非“把这件事做成前所未有的优异，让所有人都惊异”。

意味着，为了尽快完成这些任务，我们倾向于套用经验、连续加班、堆积人手，以及用生硬的管理来解决问题，而未曾想过总结和改进的方法，看清未来趋势，让自己的认知升级。

如果你是老板，你会不会在你年岁渐长的时候，继续雇佣这样的你？

最近，傅盛的《认知三部曲》大火，其中有一句很是在理：所谓成长，并不来自于所谓的位高权重，不来自于所谓的财富积累，也不来自于你掌握的某一个单项技能。像史玉柱这样的牛人，在绝境当中，他真正拥有的核心武器，根本不是资源，而是认知。所谓成长，就是认知升级

自认为企业中坚、渴望成就更多的你，从现在起，就要知道自己是不是正在用努力来感动自己，而不是输出更多的价值。然后，再分辨出自己的哪些努力是“低质量、无意义的努力”。

当洞察到这两点之后，就要马上做出改变。不论是了解和分析并坚信大趋势，还是不做井底之蛙，积极求助，亦或是活在当下，面对未来。你要做的，就是升级你的认知，你要为你的未来，争取时间。

就比如你是一个运维人员，你可能经常要面对很多持续集成、交付和部署工作。许多传统的工具和方法不仅会占用你海量的时间，而且还会将你困在“只求完成任务不出错”的低效困境之中。这时候，你应该马上升级你的认知，做出改变，去尝试AWS Codedeploy。

AWS Codedeploy是何方神圣？

下面是AWS解决方案架构师代闻老师的解读：

作为DevOps和微服务的深入践行者，Amazon在内部积累了许多持续集成、交付和部署的自动化工具和平台。其中， Apollo作为代码部署的自动化平台，每年进行超过5000万次部署。

为了能够让广大开发者和企业用户使用到功能丰富且久经考验的代码部署平台，在Apollo的经验基础上，AWS发布了自动化部署服务——CodeDeploy。

AWS CodeDeploy旨在帮助用户完成应用的快速部署，按照用户指定的策略将代码部署在一组EC2服务器上。用户策略可以包括集群部署速度、部署事件通知、警报处理策略等。此外，CodeDeploy还可以和弹性负载均衡（Elastic Load Balancer）、自动扩展组（Auto Scaling Group）等服务结合，完成无缝升级和动态部署。

为方便有效地组织部署任务，CodeDeploy设立了三个概念：应用（Application）、部署（Deployment），以及部署配置（Deployment Configuration）。

应用程序是部署的核心，由部署组（Deployment Group）和代码修订（Revisions）组成。一个应用可以包含多个部署组，一个部署组又可以包含多台EC2服务器。同时，一个服务器也可以属于多个部署组，因为一个服务器可能同时运行多个应用。

（1）部署组

创建或修改部署组时，如果添加EC2服务器，可以通过标签（Tag）对已有的EC2服务器进行筛选。所以，在创建EC2时一定要打上标签（Tag），便于在创建应用的部署组时找到对应业务的服务器。

此外，部署组还可以添加自动扩展组（Auto Scaling Group），以及用户自己机房的主机（On-Premise Instance）。

（2）代码修订

代码修订保存了当前应用涉及到得所有代码，代码的存放位置可以在S3或Github。

如果用户自建代码托管，当需要部署时，可以在工作机上同步代码到本地，然后使用AWS命令行进行打包上传。

上面的命令可以将运行目录下得代码打包上传到S3，同时显示在关联应用的代码修订一栏中。

每一次部署都有唯一的ID标记，并保存所有信息，如代码来源、部署时间、目标服务器、部署结果等。并且针对每一台服务器，都可以详细查看部署过程中的事件（如下载程序、安装前检查、 程序启动、安装后检查等7个事件），以便追踪部署的各个步骤。当部署出错时，可以快速定位和排查。

部署配置存放了一次部署的服务器台数或百分比，在发起部署时需要指定所需配置。CodeDeploy默认提供了三种配置：一次部署一台、一次部署一半数量的服务器，以及一次完成全部部署。部署发起后，CodeDeploy会按照上述策略进行工作，指导完成部署组内全部服务器的更新。

如果用户要自定义部署策略，建议使用命令行完成。比如下面的例子创建的配置就是一次完成20%的服务器部署。

aws deploy create-deployment-config --deployment-config-name ThreeQuartersHealthy --minimum-healthy-hosts type=FLEET_PERCENT,value=20

此外，CodeDeploy还可以管理物理主机（或第三方主机）。只要在物理主机上安装和配置CodeDeploy Agent，Agent向CodeDeploy注册完成后，CodeDeploy就可以像管理 EC2服务器一样在物理服务器上部署应用。

在接下来的内容里，我们会介绍：

服务器配置

服务器角色

Agent安装

用户端配置

以及案例分享

请感兴趣的小伙伴点击“阅读原文”

或扫描/长按识别下方的二维码

阅读完整版文章

代闻

AWS解决方案架构师

代闻负责基于AWS的云计算方案架构的咨询和设计，同时致力于AWS云服务在国内的应用和推广，在大规模后台架构、物联网应用、媒体行业转型、企业混合IT和自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前，在思科中国担任系统工程师，负责方案咨询和架构设计，在企业私有云和基础网络方面有丰富经验。曾任IBM中国软件开发中心软件工程师，从事企业软件和移动平台的开发工作。