持续反馈,持续改进,持续学习 - 边窗

/ 0评 / 2

疫情缘故迟迟不能上班,有人开玩笑说“再不上班就会被发现公司没有我也能正常运作了”。说笑归说笑,这话却说的在理,因为我们工作的目的不就是让公司能够没有自己而正常运作么?那一天不正是共产主义的理想吗?

如果说效率是商业的基本逻辑,那么效率同样是组织的基本逻辑,无论是改善工具,还是改善流程,亦或者是采用新的技术,终究都是为了提升工作效率,在单位时间内产出更多的结果,甚至是自动化所有的工作,自己只需要靠在椅背上看着电影、磕着瓜子,等着系统报警。这也是DevOps出现的初衷,即自动化所有手动的工作,让开发的结果替代人为的操作,所以它不仅仅是一个和运维相关的概念,而是切实和组织效率或者技术组织效率相关的概念。

DevOps有三个原则,分别是流动原则,即从业务侧向运维侧的交付流动;反馈原则,即从运维侧向业务侧反馈问题或异常;持续学习与实验原则,即持续试错、持续创新和持续学习,改善和提升组织效率。

在落地和实践DevOps时,难免会遇到与常规做法不同或与现状不同的阻碍,这需要选择合适的团队作为切入点,也就是变革的能力(关于变革推荐《冰山是怎样融化的》)。切入点可以选择大业务大团队,也可以选择小业务小团队,但重点是依据团队特点来选择,选择那些愿意尝试、愿意改变、愿意试错的团队,只要有一个成功的落地,便会吸引更多团队的加入。

相比工厂里的流水线,IT技术的产出过程具有不可见性,因此让一切可视化,让所有人都能看到、理解过程的状态至关重要。这也是为何近年来各种可视化工具层出不穷,所见即所得,可以让相关人快速做出反应,就像流水线工人看到事故或故障时立即暂停作业。

好的组织架构能够节省沟通成本,反之亦然。康威定律指出,系统设计受限于组织的沟通结构,组织规模越大,灵活性越差,这种现象也越明显。也就是系统设计会受到组织结构的影响,如果产品是分移动端、前端、后端三个团队开发,为了边界清晰,系统设计会逐渐倾向于此,如果团队更为复杂,也同样道理。组织结构有三种类型,业务型、职能型和矩阵型,三者各有优劣,但很多人只看到职能导向带来的人员成本的节省,职能专注带来的公司成本节省,却忽略了由于过度职能导向,职能部门的人只关注自己眼前的工作(他让我干啥我就干啥),由此阻碍了更高目标的实现,而这个机会成本远大过节省的成本。典型的情况是,运维不了解业务、测试不了解业务、安全不了解业务,大家只是就技术论技术,被动接受业务侧的需求(往往是要求),代价是用专业的技术实现了不专业的结果。

无论是职能导向或业务导向,都不重要,重要的是能够在各部门间建立起快速传递和快速反馈的机制。徐克曾经在《晓说》里提到自己拍电影时很羡慕TVB拍电视剧,因为电视剧可以拍一集播一集,并根据观众反应立即调整下一集的拍摄。而快速的前提是,建立高度信任的文化,即每个部门要为自己的输入和输出负责,这些年去QA的原因之一正是开发人员会把测试的工作丢给QA,觉得反正有人会给自己捡漏。

DevOps的第一个原则是建立从业务到运维侧的流动机制,包括自动化部署环境、自动化测试、自动化持续集成、自动化发布。其中发布模式有基于环境的发布模式(对环境进行变更)和基于应用的发布模式(对应用进行变更),基于环境的发布模式又可以用蓝绿部署、 金丝雀发布、集群免疫系统。

蓝绿部署,顾名思义是指有两套部署环境,通过路由可以将流量进行切换,新的变更部署完毕后通过路由将流量进行切换,但难点是需要对两个环境的数据库设计同步及回滚机制,比如备份/同步操作、应用和数据库解耦。

金丝雀发布,类似防止栈溢出的金丝雀设计,同样参考了被带下矿井的金丝雀。它是指,通过流量路由和控制,由内到外,逐渐扩大流量,测试新的部署的功能和性能,直到全部部署完毕。

集群免疫发布,是扩展金丝雀发布的做法,将发布与监控进行关联,当性能不足时自动回滚。

DevOps的第二个原则是建立各个环节的反馈机制。通过埋点也好、监控也罢,将部署、测试、发布、运维、安全等环节需要监测的内容进行可视化展现,或者进行自动化关联分析,目的是为了能够让故障或问题在被用户发现之前被自己人发现。相关的指标如平均故障恢复时间(MTTR)、平均无故障时间(MTBF)。

DevOps的第三个原则是建立持续学习和试验的环境。通过将局部的经验分享至全局,可以将经验沉淀于组织内部,而无需顾虑某个关键节点的人的“故障”,同时建立学习文化、预留一定的时间用于解决和填补技术债务有助于更好的创新。学习型组织的特点之一,是不会重蹈覆辙。

对于安全工作而言,由于天然的抵触心理,利益共融并不适合安全工作的推进,此外在人员配备上,安全人员<运维人员<研发人员。因此安全工作的推进需要全员参与,全员监督,这需要安全部门做好除技术工作之外的运营工作,比如抓住每个微小的机会普及安全常识,将原本落于纸面的安全概念开发成工具或公共服务,没有什么比让研发人员直接使用现成的安全的工具、服务更能够让他们接受的了。

以上,是《DevOps实践指南》读后的一点点感悟,其核心思想正是本文标题:持续反馈、持续改进、持续学习,它与PDCA、DMAIC、精益创业等理念一脉相承。还有很多实践并未在文中指出,这是我读过的最好的DevOps的书(毕竟几位作者正是发起DevOps概念的人),在这里强烈推荐。

知识共享许可协议  本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。

发表回复

您的电子邮箱地址不会被公开。