从电子游戏到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。

 

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