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