博客> 从电子游戏到DevOps
从电子游戏到DevOps
2019-12-06 01:44 评论:0 阅读:219 cornerstone

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

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

收藏
0
sina weixin mail 回到顶部