从电子游戏到DevOps

从电子游戏到DevOps

在一个项目团队中，开发与运维之间的关系像极了知名大型游戏《刺客信条》里的故事：开发就是追求自由的刺客联盟——我喜欢用各种新颖技术手段去满足用户爸爸那些花里胡哨的需求，你别管那技术好不好用，总之它实现了需求；运维就是那支持秩序的圣殿骑士——我要的是稳定运行！稳定运行！稳定运行啊！

于是，产品与运维之间形成了一道墙。

开发部门夜以继日地打造出自己的“杰作”，并怀着今晚就能开庆功会的心情把自己的“杰作”交给了运维部门，殊不知墙那面的运维们对开发的抱怨才刚刚开始：

l 这款优秀的产品在目前的底层平台上无法运行，因为这个平台太古老了，因为这个平台空间不足，因为这个平台不支持某某版本……

l 这款产品的体系结构跟我们的{存储，网络，部署，安全}模型不匹配。

l 这款产品的报告、安全、监视、备份balabalabala 我们搞不懂 ，所以没法把它做成实际可用的产品。

当运维将问题源源不断地反馈给开发后，开发的回复一定是：

l 这不是我们的错，我们的代码非常完美，是（运维部门的）部署做的太差劲了。

l 运维部门比较笨，他们不懂新技术，为什么他们没法实现最新的技术呢？为什么他们这么落伍呢？

l 在我的机器上运行的没问题啊……

刺客联盟与圣殿骑士互掐了几百年，但事实上他俩都不过是想维护人类文明；开发与运维互看不顺眼，但他们的初心都是想这个项目能顺利验收。

虽然开发和运维这样相爱相杀的关系看上去和游戏很像，但其对项目的危害性可不是游戏，开发与运维陷入一场暴风骤雨，客户则成了蒙受损失的一方，最终团队失去了客户，失去了金钱，失去了项目。

DevOps就是为了让开发和运维告别这样的悲剧而被提出的。它是一种框架，包含了很多优秀想法和原则，它重视开发部门和运维部门打破隔墙，通力合作。

DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了下面这个DevOps能力图，良好的闭环可以大大增加整体的产出。

在DevOps环境中，开发人员和系统管理员会构建一些关系、流程和工具，从而更好的与客户互动，最终提供更好的服务。

DevOps的三大原则

基础设施即代码

DeveOps的基础是将重复的事情使用自动化脚本或软件来实现，例如Docker（容器化）、Jenkins（持续集成）、Puppet（基础架构构建）、Vagrant（虚拟化平台）等；

持续交付

持续交付是在生产环境发布可靠的软件并交付给用户使用。而持续部署则不一定交付给用户使用。涉及到2个时间，TTR（Time to Repair）修复时间，TTM（Time To Marketing）产品上线时间。要做到高效交付可靠的软件，需要尽可能的减少这2个时间。部署可以有多种方式，比如蓝绿部署、金丝雀部署等；

协同工作

开发者和运维人员必须定期进行密切的合作。开发应该把运维角色理解成软件的另一个用户群体。协作有几个的建议：a、自动化（减少不必要的协作）；b、小范围（每次修改的内容不宜过多，减少发布的风险）；c、统一信息集散地（如wiki，让双方能够共享信息）；d、标准化协作工具（比如jenkins）。

DevOps的影响

交付

使用DevOps有多爽？有调查报告发现，在2016年，根据全球4600位各IT公司的技术工作者的提交数据统计，得出使用DevOps的公司团队平均每年可以完成1460次部署。与传统组织相比，DevOps组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。

协调合作

强有力的发布协调人弥合了开发与运营之间的技能鸿沟和沟通鸿沟，采用电子数据表、电话会议、即时消息、企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。

自动化

强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

如今，IT行业已经越来越与市场的经济发展紧密挂钩，能否让公司的IT配套方案及时跟上市场需求的步伐，在今天显得至关重要，DevOps或许就是给与公司和团队的一剂良方。

最后推荐几个在实现DevOps上已很成熟的项目管理工具：CORNERSTONE、Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker。

要说这些工具各有什么特色，改天我们再聊吧。话说不知道刺客信条故事的最后结局会不会也和运维与开发一样，最终两个派系握手言和共同进退呢……