现在只要搞开发的人，都在谈微服务，只要搞运维的人，都在谈 DevOps，但对于大部小伙伴来说几乎没什么经验，对于大部分企业来说也只处于尝试阶段，虽说如此，可感觉大家在制定目标时，都不太喜欢给自己留余地，把规划写得很大，功能很全，甚至恨不得一夜之间所有问题都会通过微服务与 DevOps 的设想凭空消失。
早在上半年，我曾通过 「GTLC - Open Space」资产配置时代来临，平台化演进中的问题与挑战 向大家介绍过好买在这几年中实施 DevOps 的一些经验与教训，但绝大多数内容偏向于技术，对于其他方面说的太少，从本文起，我将通过一个系列向与大家聊一聊 “我们在实施 DevOps 时遇到的挑战”
切换敏捷之前的过渡区
对于许多草根程序员来说，提到敏捷所能带来的收益，条件反射的会说 “能快呀”、“不用写文档啦”
不能说这种说法有问题，只是不够专业，在实际的工作中，我们是否经常会听到这样的对话？
行，就按照你说的做，我写个需求规格说明书给你
好的，写完别忘记给领导审批，然后我按照需求做个设计给你看下
……
开发结束啦，已经提测了，你问问测试吧
……
问问测试吧，什么时候可以发布仿真环境
……
又改需求了？别忘记先改需求规格说明书，要不然代码和文档对不上了，改完我再开发
……
对于长期适应于「需求 -> 设计 -> 开发 -> 测试 -> 运维」的企业来说，直接切换至敏捷模式，无论对业务、技术及架构都是非常具有挑战的，这种挑战多半来自于业务场景与公司文化的限制，甚至是组织结构的局限性，不但不能快起来，甚至会带来一些意想不到的灾难
（图文：职能化筒仓式组织结构）
先用迭代让业务快起来，敏不敏捷不着急
对于金融类企业来说，多半是业务驱动模式，业务关心的是 “快上线” 、 “别出事”，至于技术是用什么实现，敏捷也好，糊上墙也罢，他们其实并不关心
为了快速让业务获得收益，在采用敏捷之前我们选择迭代进行过度
举例说明下迭代给业务带来的价值：要计划制造一辆汽车，它最核心的功能是可以在路上跑，所以我们可以先制造一个踏板车，依次迭代为滑板车，自行车，摩托车，汽车
（图文：正确理解迭代的方式）
瀑布 - 迭代 - 敏捷，三者的差异是啥呢？
（图文：瀑布与迭代的区别）
（图文：瀑布的特点）
（图文：迭代的特点）
（图文：迭代与敏捷之间的区别）
大家都缺乏敏捷文化
从某种角度来讲，目前我们还是按照 「职能化筒仓式组织结构」进行分工协作的，开发和运维部门经常会坐在一起探讨，就运维流程如何改变、自动化能力如何建设等，然而自始至终无法突破的终极问题就是：无论我们如何改变，如果万一生产环境出了问题，谁承担责任？因为 DevOps 能力的建设需要一个过程，开发团队不敢承诺完全承担责任；而运维因为弱化审批和控制力，也认为不该为其承担责任。最终不了了之。
其实，使用迭代过度也只是权宜之计，真正的问题出在文化上，旧有的组织治理模式产生了各扫门前雪的官僚文化，没有责任共担，以及出现问题必然问责的文化。这种文化可能源自惯性的职能化思维，可能源自组织的绩效考评和激励制度。
（图文：跨职能产品化的组织结构）
这是 ThoughtWorks 在一篇 DevOps 文章中所提到的，我觉得一针见血，不过对于大部分企业，尤其是金融类企业，实践落地所付出的周期与成本可能会更大一些。
再举个例子，在 「讲个‘理论型’高可用架构的故事给你听」我曾经说过，我们的架构部模仿饿了么的 “随机故障测试系统(Kennel)” 自研了一套 “混世魔王”，英文名叫“ChaosDevil”，这个 “魔王” 会根据策略每隔一段时间随机将生产环境服务器关闭，以此来测试生产环境的快速恢复能力，促使各团队提升系统的稳定性；
有趣的是被指定优先使用的团队口头全力支持，但实践起来却迟迟延误，当然大家都比较忙，这也是可以理解的。不过我们可以设想下，如果没有这个“魔王”，大家可以给领导讲自己的系统很稳定（只要没出问题）；
然而这个 “魔王” 可能会随时暴露出自己的系统并不像自己所宣称的那样稳定，会降低自己在上级心目中的“有能力”印象，随之而来的可能就是问责、惩罚；
这样的文化下，大家真正关心的是如何给领导“表现”，而不是在真正的系统稳定性上追求卓越。
所谓敏捷文化是个啥？
抄袭一张图吧，简单点
（图文：敏捷，乃至 DevOps 所需要的文化）
本文转载自头哥侃码公众号。
原文链接：https://mp.weixin.qq.com/s/Oy_bb3B8pAhIkjvCQOJWjw
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论