从电玩到DevOps在一个项目组里，开发和运维的关系很像知名大型游戏里面的故事《刺客信条》：开发就是联盟追求自由的刺客——我喜欢用各种新奇的技术手段来满足用户爸爸的花哨需求。你不管这个技术好不好，总之满足了需求；运维是支持秩序的圣殿骑士——我要的是稳定运行！稳定运行！稳定运行啊！从而在产品和运维之间形成了一道墙。开发部夜以继日地打造自己的“杰作”，带着今晚开个庆功会的感觉，把自己的“杰作”交给了运维部。刚开始：l这个优秀的产品不能在当前底层平台上运行，因为平台太旧，因为平台空间不足，因为平台不支持某个版本...l这个产品的架构和我们的差不多{存储、网络、部署、安全}模型不匹配。l我们不了解这个产品的报表、安全、监控、备份balabalabala，所以没法把它做成一个实用的产品。当运维不断向开发反馈问题时，开发的回复一定是：l这不是我们的错，我们的代码是完美的，是（运维部）部署太差了。l运维部门比较笨。他们不了解新技术。为什么他们不能实施最新的技术？为什么它们如此过时？l在我的机器上运行正常...刺客联盟和圣殿骑士团争斗了数百年，但实际上他们都只是想维护人类文明；开发和运维互不看好，但他们的初衷是想让这个项目顺利通过。开发和运维之间的相爱相杀的关系虽然看起来像游戏，但它对项目的伤害却不是游戏。开发运维陷入风波，客户成为损失方。最终，团队失去了客户、金钱和项目。DevOps的提出就是为了让开发和运维告别这样的悲剧。它是一个包含许多优秀思想和原则的框架。强调开发部门和运维部门打破壁垒，协同工作。DevOps希望实现的是打通软件产品交付过程中的IT工具链，让各个团队减少时间损失，更高效地协同工作。专家总结了如下DevOps能力图，一个好的闭环可以大大提高整体产出。在DevOps环境中，开发人员和系统管理员建立关系、流程和工具以更好地与客户互动并最终提供更好的服务。DevOps的三大原则，infrastructure,code，DeveOps的基础就是用自动化的脚本或者软件来实现重复的东西，比如Docker（容器化），Jenkins（持续集成），Puppet（基础设施建设），Vagrant（虚拟化平台）），ETC。;持续交付持续交付是在生产环境中发布可靠的软件并交付给用户。持续部署不一定交付给用户。涉及到2次，TTR（TimetoRepair）维修时间，TTM（TimeToMarketing）产品上市时间。为了高效地交付可靠的软件，有必要尽可能地减少这两个时间。部署可以采用多种方式，比如蓝绿部署、金丝雀部署等。协同工作开发人员和运维人员必须定期密切合作。开发应该理解作为软件另一个用户组的运维角色。有几个合作建议：自动化（减少不必要的协作）；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、Pivo??talTracker。要说这几个工具各自的特点，改天再说吧。说到这里，不知道刺客信条的故事最终结局会不会和运维开发一样。最终，两派握手言和，共同进步……
