摘要：运维部门比较笨，他们不懂新技术，为什么他们没法实现最新的技术呢为什么他们这么落伍呢在我的机器上运行的没问题啊刺客联盟与圣殿骑士互掐了几百年，但事实上他俩都不过是想维护人类文明开发与运维互看不顺眼，但他们的初心都是想这个项目能顺利验收。
从电子游戏到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。
要说这些工具各有什么特色，改天我们再聊吧。话说不知道刺客信条故事的最后结局会不会也和运维与开发一样，最终两个派系握手言和共同进退呢……
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/114886.html
摘要：微店技术团队公众号容器化之路这是一套以阿里云为基础，为核心，第三方服务为工具的开发测试部署流程，以及内部的代码提交，版本管理规范。如何打造安全的容器云平台对，微服务，来说都是非常好的落地实践技术。 在使用 flow.ci 进行持续集成的过程中，也许你会遇到一些小麻烦。最近我们整理了一些常见问题在 flow.ci 文档之 FAQ，希望对你有用。如果你遇到其他问题，也可以通过「在线消息」或...
摘要：围绕软件工程效率提升进行一系列技术内容分享，包括国内外持续集成持续交付，持续部署自动化测试等实践教程工具与资源，以及一些工程师文化相关的程序员。划分了数据库日志安全监控配置管理云服务等个大类，个工具。 CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外持续集成、持续交付，持续部署、自动化测试、 DevOps 等实践教程、工具与资源，以及一些工程师文化相关...
摘要：但是坦白说在安卓，开发者并不能控制所有的事情。结论现在，安卓应用程序也可以呼应活动，拥有强有力的持续交付了。 DevOps 是一种广为人知的活动，其主要目的是使软件交付自动化。的确，DevOps 的目标是持续测试、代码质量、功能开发和更轻松地进行维护更新。因此，DevOps 的终极目标之一是让开发者可以执行快速可靠、自动化的发布，理想状态下，整个流程都不需要人为操作。这被称为持续交付。...
摘要：李时软件部中国区总经理，将在本次开放日带来软件实现企业转型的分享。李时早在两年前就在全球范围内提出了建设新形态的战略。软件测试的云化众测化似乎是一种趋势，您怎么看待软件测试的趋势李时软件测试的技术一直是在不断的推陈出新，不断的向前发展的。 2016年7月22日，「HPE&msup软件技术开放日」将在上海举办，msup携手HPE揭秘全球测试中心背后的12条技术实践。 李时：HPE软件部...
摘要：正在走远，新年之初，小数精选过去一年阅读量居高的技术干货，从容器到微服务云原生，汇集成篇精华集锦，充分反映了这一年的技术热点走向。此文值得收藏，方便随时搜索和查看。，小数将继续陪伴大家，为朋友们奉献更有逼格的技术内容。 2017正在走远，新年之初，小数精选过去一年阅读量居高的技术干货，从容器、K8S 到微服务、云原生、Service Mesh，汇集成52篇精华集锦，充分反映了这一年的技...
阅读 2489·2021-11-18 10:02
阅读 748·2021-11-17 09:33
阅读 311·2019-08-30 11:16
阅读 2375·2019-08-29 16:05
阅读 3236·2019-08-29 15:28
阅读 1287·2019-08-29 11:29
阅读 1564·2019-08-27 11:07
阅读 1827·2019-08-26 13:51
