企业外包环境下的DevOps运维.docx

企业外包环境下的DevOps运维1. 面临的挑战今年的2018GOPS·深圳站设了金融和通信专场。因为金融和通信行业面临着互联网最大的冲击。有了微信和QQ，谁还发短信？有了支付宝和微信支付，谁还随身携带银行卡？这些是互联网行业对金融和通信行业带来的冲击。传统行业和互联网行业差别巨大，我暂且不谈体制上、流程上、管理上、人员上的差别，今天我们谈谈IT上的差距。传统行业以“交钥匙”模式为主，厂家开发完成后，拿包过来现场部署。运维成本高尚且不说，毕竟花的是国家的钱，最麻烦的是效率和质量特别差。对面的互联网行业主要是自研自维，他们用的是DevOps体系，高效高质的交付，灵活地应对变化。?2. 实践DevOps的道路选择如何学习DevOps体系，有不同的选择。有些国企、传统行业选择依赖外包，希望通过外包带动我们转型。这就像“输血”，把外部新鲜血液输入到传统企业里。“输血”很好，可以解燃眉之急，但我们不能一直依赖它。自研自维的全面转型，我们称之为“换血”，运营商在推全面IT化、数字化转型，招一大批计算机专业的新员工，组织大量的IT培训，希望可以学习自主研发，自己运维整个网络体系和IT体系。这是一个很好的愿景，但同时它是很难实现的。在实现过程中，可能会面临很多坎坷。所以我们选择了培育基因，持续改良这条“造血”之路。3. 技术的实践3.1 选择普适、完备的体系来对标学习培育基因，总得有基因，基因从何而来。每个互联网行业都有自己的特性，也有其成功之处，难以全盘复制。所以我们应该找普适完备体系，我向大家推荐两个比较好的体系，一是高效运维社区的DevOps道法术器，二是中国信息通信研究院的《研发运维一体化能力成熟度模型》。道法术器，中国风特别浓，我文化水平不高，不太敢学，还是来学国标吧。中国信息通信研究院DevOps模型，当中包括42个过程，难以全学。比如敏捷开发管理，传统行业之前以外包为主，外包哪有敏捷开发，你连代码都没有。“在瓶颈之外的任何地方作出的改进都是假象”—艾利?高德拉特《目标》3.2 选取六大过程，优先解决痛点我们需要从42个过程中选取切入点，用来解决目前的瓶颈和痛点。广东移动选择了以下六个过程作为切入点，一是故事与任务排期，管理需求的涉众期望；二是部署与分布模式，痛点是改进版本上线效率；三是应用监控，为了解决故障定位慢的痛点；四是事件响应及处理，解决的是故障处理的痛点；五是高可用规划，提升系统可靠性；六是度量指标，定性定量评估DevOps转型效果，持续优化。3.3 选取六大过程，优先解决痛点3.3.1 第一个过程——故事与任务排期传统行业IT管理部门经常被用户部门投诉：半年过去了，我提的需求怎么还没开发。厂家很痛苦，个个都是大爷，随时随地加塞需求，个个都说自己的需求最紧急，我敢得罪谁？我们作为IT管理的角色，也很无奈，年初问大家有啥需求，个个不提，年中个个说急。比方说，集团2、3月份开工作会，1月份立项，立项时没需求，开完年度工作会提出一堆的需求。老板很困惑，到底是厂家不给力还是我们管理水平差，为什么大家都不满意。我们的药是管理好各方期望。我先声明一下，这个药并不能提高需求交付的速度，那个要等全盘引入DevOps敏捷开发体系才能解决。在DevOps体系还没落地之前，我们先管好各方期望，先让用户和老板不那么痛苦，我们自己也不那么痛苦，先缓解痛苦了，再考虑后面的改进。需求管控分成两部分，一个是年度资源的管控，也就是制定年度版本发布计划。关键点是“排车次，分车票”。年初工作会还没开，我们可以根据项目金额和人天单价估算，估算全年可用的人力资源，假设有1.2万人，制定全年版本的分配计划。有点像列车时刻表一样，需求在哪天截止、哪天受理、哪天排版、哪天上线。分配各版本的资源数量，根据全年闲忙规律安排各个版本的资源数量。12个月里，并不是每个月都平均分配，年底特别忙，需求特别多，我们要为第三第四季度多安排。分配用户的资源比例，不是平均分配，要看谁对系统要求提得多。去年这个部门提出60%的需求，来年我给他们分60%的资源，年初分车票，用完车票只能等着，要不就只能向其他有车票的人协调。预留10%的机动资源，紧耦合系统功能要统一发车时间。日常需求的管控，采用列车模式，这个概念在高效运维社区的公众号里面有提到，大家可以去看看。列车模式重点在于开两会、出车许可、按时出车。这个需求能不能做，通过开设计评审会来确定，这个需求急不急，什么时候做，通过用户需求排版会来确定。我们管理用户的需求，无非是让谁来定厂家的开发资源，给谁用。所以，解决问题的根本，其实只需要把权力还给业主就好了。作为IT开发的管理部门，凭什么你说了算，一定是业主说了算。以后业主就不会再说：给你提的需求都过了半年了为啥都没做，因为业主可以自己决定，把紧急的需求排进两会。管好期望，皆大欢喜。大家知道发