DevOps实施经验分享.pdfVIP

DevOps 实施经验分享 1 当下只要搞开发的人，都在谈微服务，只要搞运维的人，都在谈 DevOps ，但对于大部小伙 伴来说几乎没什么经验，对于大部分企业来说也只处于尝试阶段，虽说如此，可感觉大家在 制定目标时，都不太喜欢给自己留余地，把规划写得很大，功能很全，甚至恨不得一夜之间 所有问题都会通过微服务与 DevOps 的设想凭空消失。而从本文起，我将通过一个系列向与 大家聊一聊 “我们在实施 DevOps 时遇到的挑战”。 挑战一：敏捷文化 1 、切换敏捷之前的过渡区 对于许多草根程序员来说，提到敏捷所能带来的收益，条件反射地会说 “能快呀”、“不用 写文档啦” 。 不能说这种说法有问题， 只是不够专业，在实际的工作中， 我们是否经常会听到这样的对话？ 行，就按照你说的做，我写个需求规格说明书给你 好的，写完别忘记给领导审批，然后我按照需求做个设计给你看下 …… 开发结束啦，已经提测了，你问问测试吧 …… 问问测试吧，什么时候可以发布仿真环境 2 …… 又改需求了？别忘记先改需求规格说明书，要不然代码和文档对不上了，改完我再开发 …… 对于长期适应于「需求 - 设计 - 开发 - 测试 - 运维」的企业来说，直接切换至敏 捷模式，无论对业务、技术及架构都是非常具有挑战的，这种挑战多半来自于业务场景与公 司文化的限制，甚至是组织结构的局限性，不但不能快起来，甚至会带来一些意想不到的灾 难。 （图：职能化筒仓式组织结构） 3 先用迭代让业务快起来，敏不敏捷不着急 对于金融类企业来说，多半是业务驱动模式，业务关心的是 “快上线” 、 “别出事”，至 于技术是用什么实现，敏捷也好，糊上墙也罢，他们其实并不关心。 为了快速让业务获得收益，在采用敏捷之前我们选择迭代进行过度。举例说明下迭代给业务 带来的价值：要计划制造一辆汽车，它最核心的功能是可以在路上跑，所以我们可以先制造 一个踏板车，依次迭代为滑板车、自行车、摩托车、汽车。 4 （图：正确理解迭代的方式） 瀑布 - 迭代 - 敏捷，三者的差异是啥呢？ （图：瀑布与迭代的区别） 5 （图：瀑布的特点） （图：迭代的特点） 6 （图：迭代与敏捷之间的区别） 2 、大家都缺乏敏捷文化 从某种角度来讲，目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的，开发和运 维部门经常会坐在一起探讨，就运维流程如何改变、自动化能力如何建设等，然而自始至终 无法突破的终极问题就是：无论我们如何改变，如果万一生产环境出了问题，谁承担责任？ 因为 DevOps 能力的建设需要一个过程，开发团队不敢承诺完全承担责任；而运维因为弱化 审批和控制力，也认为不该为其承担责任。最终不了了之。 7 其实，使