Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

谈谈 Ops(二):流程和人

Posted on 01/28/201906/23/2019 by 四火

第二部分,我想谈一谈流程,依然来源于我的理解。Ops 的实践上面,有两部分内容紧密结合,不但共同显示了 Ops 的生产力,也在相当程度上体现了 Ops 的技术水平。这第一部分就是流程,也是今天要说的内容,另一部分是工具(也包括和使用工具相关的技能),下一次再说。

我认为 Ops 可以分为几个层次,最次的的一层,其特点是重度依赖于的人的直接 “操作”。风险管理、因果行为,都通过流程来统一把控,并且遗憾的是只有流程——除了它基本没有可靠有效的工具,或是其他办法。

其实,流程本是个好东西。有时候某些工程师被散漫和自由主义惯坏了,听到流程就反感。事实上,流程在很多情况下都有着举足轻重的作用。它们很容易控制,也很容易实施,基本是立竿见影,在不想要深入,不想要挖掘原因和研究对策的时候,流程上做一点改进,很快就能看到效果。

举个例子来说,多数的公司和团队,在线上代码发生变更的时候,都需要进行风险管理,这里面几乎一定会有流程。比如或最有名的叫做 “变更管理”(change management)的请求,一般由开发人员撰写这样的请求,然后由项目经理和 Ops 的责任人审批。这样的请求中,需要包括诸如变更内容、必要性、风险、部署步骤、验证方法、回滚方式等等内容。这样的目的,在于尽量把变化的因素变成预期内的、可控的因素,尽早发现可能存在的问题,降低风险。

但是,流程这样的方式,也有着负面效应。最大的效应就是,它单纯地固化行为,而拒绝人主动的思考。就像几年前国内热炒的 “敏捷” 一样,流程不应该是本质,工具也不应该是本质,只有人才是本质。

在我曾经的一个团队中,在项目发布以前的最后阶段,有限的时间里面(一般都是一个晚上),需要把最重要和最核心功能过一遍,这个功能清单叫做 checklist。为什么不把所有的测试案例都覆盖了?因为时间有限。这就是一个很简单也很容易执行的流程。但是,随着时间推演,问题变得很多。比如产品发布了以后,发现有一个比较大的问题,于是研发团队就要回溯问题,发现问题以后,为了杜绝问题的再次发生,就打算采取某些措施。(到目前为止做法上面都没有什么问题,可接下去就有争议了。)于是一条用于检测这个问题的识别项被加到这个 checklist 当中。这里面有很多检查项事实上在问题修复以后是不会再出现的了,也有一些检查项明显是用于覆盖位于边角的 corner case,而不是主要的 case,但是既然出过问题,为了保险起见,还是都加进去了。就这样,随着时间和版本的演进,这个 checklist 变得越来越长,某些验证项的执行难度颇为复杂,在几年以后,已经到了几个小时都无法过完这个 checklist 的地步,于是这个流程就变成了一个越来越难以执行的累赘。

造成这一问题的原因是什么,就是流程太简便了,太有效了,以至于这些聪明人不再思考应该采用什么样的方式来从根本上彻底地解决问题。

现在我不想进一步分析上面的问题,而是来看看这样一个争议。这个 “古老” 的争议和流程关系密切,到底应该保留单独的测试团队,还是应该让开发来做测试?

无论你对这个争议的观点如何,无论二者取舍的利弊如何,无论这两种结论的场景适用性如何,这个争议本质上反映了一件事——我们是应该用更多流程加上多个单一职责的团队来解决问题,还是用更少流程加上单个承担多种职责的团队来解决问题?

在回到上面 checklist 的那个问题上,这个问题恰恰出在开发和测试团队单独运作的体系之中。有人问,这些新增加的问题中,既然有一些检查项是不会再出现的,既然有一些检查项覆盖的是边角非主要用例,为什么大家还要同意加上去?这就和上面说的测试和开发团队分离的情况有密切关系。因为测试团队多数都做不到白盒,不知道实现,只想用输入输出覆盖黑盒用例的方法来保证正确性,因而所谓的问题 “不再出现” 就无从谈起;而团队和人一样,一朝被蛇咬,十年怕井绳,出过问题,不知道实现,也自然没有人愿意承担这个再出问题的风险,哪怕它曾经说一个边角的 case。

事实上,这个争议的观点可以扩展到更多角色。不要以为只有测试团队遇到这样的困惑。Ops 也是如此——到底应该保留单独的运维团队,还是应该让开发来做运维?

于是,我听过 Ops 团队的朋友说过这样的话,听起来很有意思:

如果线上问题少,boss 说,要你们何用?

如果线上问题多,boss 说,要你们何用?

当然,这些争议,最终都需要达成某种平衡,没有一种方法是放在所有场景下的万全之策。比方说,一些 AWS 服务中,Ops 的比重居然占到了 85% 以上。且不说其最终的合理性,市场和人才等方面的策略永远制约着团队去寻找最优雅的解决方案,而是选择最 “合理” 的解决方案,即便如此,和其庞大的基础设施业务相比,其 Ops 团队依然是小而优秀的。这些单独的 Ops 可能在整个服务的漫长生命周期中始终无可替代,没有他们,开发团队也无法专注于核心功能,而要被大量的 Ops 事务困扰。这也是为什么许多互联网大公司在推行小团队和综合型团队,强调工程师职责需要覆盖 Development、QA 和 Ops 三部分的同时,依然保留少量的独立 QA 团队和独立 Ops 团队。

再从公司和团队发展壮大的角度观察流程在 Ops 中的变化。

在一家公司还小的时候,团队更为原始,但是 Ops 却更容易聚焦在核心问题上面。用户有困难?解决困难。产品有问题?解决问题。没有繁荣缛节,也没有太多可以复制的模式和需要遵循的流程。慢慢地流程多了起来,人做的事情也更加专业,这里可能会达到一个最佳的平衡点。因为再往后,因为那些流程的过度复杂性和开销,使得效率和质量的平衡被打破,一切向着低效和臃肿慢慢滑落。

从这个角度说,互联网公司在这方面要比传统企业更懂得简化和合理化流程的重要性。即便在公司壮大以后,依然有一些自下而上的反馈行为帮助这件事情发生。

总的来说,Ops 和 Dev 一样,兼具影响力、效率,以及风险。和 Dev 比起来,Ops 往往更为枯燥,不可控性更多,有时候不得不响应一些紧急的事情。对于从这三者的角度看来,流程更多地,是用来在效率损失可以接受的情况下,控制风险,从而导向正向的影响力。对于一些服务更 critical 的团队来说,风险控制相对地,更为重要,因而流程的比重可以适当增加;反之,流程需要简化,保证效率在一个高标准之上。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 谈谈 Ops(一):我的运维经历
  2. 谈谈 Ops(三):事务、团队和时间分配
  3. 手滑的故事
  4. 谈谈 Ops(汇总 + 最终篇):工具和实践
  5. Process and Corporate Culture

4 thoughts on “谈谈 Ops(二):流程和人”

  1. 凯瑞 says:
    08/13/2024 at 5:49 AM

    部分人已经失去全面思考能力,成了按照流程或者规范规定的方面填空题
    比如用 5 视图方法进行架构,以为填满 5 个视图就架构完成了
    比如测试用例,本来测试的是需要从逻辑上思考一下测试是否覆盖,实际执行的时候几个人将用例一份,即使遗漏一个很明显的业务分支,也淡淡说一句用例缺少了
    还记得美国那个案子,医生手抖了将药的单位选错了,抓药者,护士,以及最后的患者都是直接吃。 太依赖流程和作为自动化而失去主动识别风险的意识,这是流程带来最大的问题。

    那么怎么使用流程呢
    在事前准备阶段需要全面考虑 这是人的事
    在逻辑上可以自恰后,可以用流程来检查考虑是否全面
    然后将考虑的点根据流程规定的范式记录下来
    最后严格执行流程

    最后是管理者的监控,而非警察式的监控

    Reply
  2. Jesse says:
    02/24/2019 at 10:13 AM

    1. 我个人觉得有效的流程的作用始终是要大于人的,流程不会有疏忽,人肯定会有。
    2. 流程上效率的问题,感觉是两方面:
    – 整个流程长度过长:这说到底还是一个取舍的问题,只保留核心而必要的流程
    – 单个流程流转过慢:如果是自动化的流程,可以优化。如果是人工的流程,做成自动化,否则,其实还是人的问题。

    Reply
  3. laixintao says:
    01/30/2019 at 9:53 PM

    写的太好了,参加过几次复盘会议之后,感受颇深。很多人喜欢 “添加流程” 来防止此故障再次发生,实际上这带来的成本远高于小几率故障带来的损失。

    Reply
  4. coco says:
    01/29/2019 at 9:30 AM

    快过年了 四火老哥 新年快乐。

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme