在技术团队的日常管理工作中，一个管理者做得最多的事情是决策、开会，最不想看到的是线上事故，线上事故给技术团队带来非常大的冲击，而给线上系统带来风险最大的研发环节是线上环境的变更，甚至有人说：「没有变更就没有问题」，对此我们不置可否，但这些变更之所以会导致事故，从根源上来讲大部分是技术同学犯了错。
这里的决策、会议，变更，错误合起来是我们日常工作中的大部分。而对于这些的基本认知是一个技术管理者在带团队过程中逐步提升的，今天我们就来聊聊这 4 个基本认知。
1 决策
在带团队的过程中我们会做非常多的决策，如去决策是否投入足够大量的人力满足某个业务，或者升级架构，或者构建某个流程机制等等。
这些决策中从服务于时间维分为两种：
- 当下的决策，如评估需求优先级，先做什么，后做什么，关注的是当下和已有的；
- 未来的决策，如评估技术架构演进、团队演化和发展等等，关注的是未来。
当下的决策在我们的工作中最常用于评估产品需求、评估技术方案或实现方案。
对于产品需求，技术管理者的作用是把价值不高，或者没有价值的需求干掉，不让其进入研发，不让公司的人力成本白白浪费掉。一般我们会对于提需求的同学问如下的问题：
- 为什么会有这个需求？ 一般是想看这个需求是怎么来的，用户故事是怎样的；
- 这个需求的价值是什么？ 一般是想看这个需求做了之后对产品或业务的好处，看产出；
- 如何度量这些价值？ 一般是想通过数据看到需求的价值，把价值反馈在指标上，如营收指标、效率指标等。
对于技术需求或技术方案，技术管理者的作用是来评估当下的选择是否正确。一般我们会评估如下的点：
- 有没有做过方案评估，即有没有评估过业内的方案、公司内的方案以及对于当下的现况的分析；
- 是否合理的方案，有没有明显的缺陷或漏洞；
- 有没有显得特别高大上，特别先进，防止过度设计，浪费资源。
未来的决策更多是管理者站在当下思考团队的发展，人员的发展和技术架构的发展等，是一种未雨绸缪的远见。
是基于公司战略，在组织的先进性、技术的先进性的前瞻性布局。如现有的人才梯队和人才密度是否能满足公司三到五年的发展，现在的技术架构是否能满足公司三到五年后的战略，对于行业内新的技术是否我们需要扩大资源投入，去预研并应用在业务中。
这些前瞻性的决策都是管理者基于对公司业务和业务未来发展有足够的认知和理解后做的。
我们所做的这些决策都是以有限的资源达成我们的目的，其本质是资源的分配。当我们分配资源的时候，最最重要是看投入产出比以及和公司战略的方向是否一致。
2 变更
这里的变更是指生产环境的变更。首先我们看一下定义，什么叫生产环境？生产环境是指服务于客户的应用及其运行环境，以及和这些环境相关联的环境和系统。
如果一个应用或环境和生产环境有接触，那它也是生产环境。
什么叫变更管理，变更管理包括什么？
变更管理是指以可控的方式对线上的服务、配置或基础设施进行变更，从而减少变更对业务和服务质量的影响，快速处理变更可能带来的问题，提升系统的稳定性。
在日常工作中我们见到变更有如下 4 种：
- 应用变更，也称为代码变更，是我们最最常见的变更类型，主要是通过修改代码改变应用程序并通过发布系统发布到线上。这也是我们变更管理中风险最大的地方，因为变更的人，变更的位置和逻辑等都是不确定的。除了正常的发布变更，应用的回滚也是应用变更的一种，因为其改动了线上的应用；
- 配置变更，是指应用系统的配置变更，一般是通过配置系统来变更，触发线上应用的热更新或滚动，配置如果是写死在代码中，会变为代码变更；
- 基础设施变更，此变更一般是运维同学来操作，可能涉及网络设施变更，服务解析变更等等，如 DNS 的解析，网络安全配置等等，这些都算到基础设施变更里面，而不是配置变更，又如宿主机挂了，需要替换宿主机，此时也会导致基础设施的变更；
- 容量变更，此处单独列出是因为相对于基础设施，容量变动的影响逻辑不一样，其主要是通过垂直或水平的方式提升系统的容量，特别是当出现容量告警的时候，此变更经常由运维同学手动，或者系统自动触发。
那么如何控制变更？这里我们先提一下变更管理的标准流程。
变更管理的标准流程：
- 变更申请：在我们的流程中可能是创建发布记录，或者申请紧急发布
- 变更评审：变更评审主要是检查变更过程是否完备，以降低变更的风险，其包括如下内容：
- 就绪分析：材料是否完备，人员、设备、软件、网络是否就绪，测试是否达到上线要求等。
- 风险分析：架构、性能、业务、合规等方面的风险评估，变更内容是否属于需求范围，变更是否可控。
- 重要程度：变更属于一般、重要、紧急、标准哪一种。
- 变更审查：内容是否满足业务需求，内容是否通过测试，测试是否全面、有效。
- 应急管理：变更步骤、应急方案、回滚方案、应急预案是否完备。
- 变更实施：变更计划时间如何安排，发布及回退操作步骤是否完备，自动化步骤情况。
- 变更验证：变更涉及的业务、技术验证方法与时间安排。
- 变更审批：相关负责人对于变更评审的结果进行确认，并审批通过。
- 变更执行
- 根据发布计划执行发布操作，一般应该有一个灰度的过程；
- 验证线上功能并回归主流程；
- 持续灰度，观察用户直到灰度完成。
- 变更验收
- 对发布的功能进行验收，对于影响范围内的功能进行验收，对业务主流程进行回归验收；
- 留守，并观察日志、监控服务负载等，这个操作是为了及时发现验收检查漏掉的问题，或者及时处理隐藏的问题，以减少变更后产生的问题对线上业务的影响。
我们做这个流程是形式上的安慰，还是僵化的惯性，还是能真正地解决问题，是我们在做这个流程以及执行这个流程中需要着重思考的问题。
在变更前，即我们变更线上环境前需要自己做 Code Review，以及交叉的检查，以尽量减少问题流转到后面的操作中，节省问题的处理成本。
变更管理没有银弹，我们能做的是控制节奏，敬畏线上，以更机制化的方式提前发现问题并解决问题。
3 会议
会议是一个相互沟通、交互信息、形成一致看法，从而解决问题的管理工具。
从会议的定义来看，会议是一些人有组织、有领导地为了某种目的而进行讨论和商议的集会。
当我们思考一个会议要不要开时，可能需要先思考这个会议的目的是什么。
如果一个会议没有需要讨论的地方，没有明确的目的，可能大概率是一个不需要开的会的，又或者仅仅是一个简单的信息同步，直接文档或者在群里同步就可以了。除非文档没法完全解决问题，比如一些战略的宣讲，一些大的事项的发布，需要有一个仪式感的会，现场答疑的会。
如果发现两个会的参会人差不多，那么是否取消其中的一个会呢？不一定，看目的是否一致，如果解决的问题不一样，可以同时存在。
回顾我们常开的几种会议。
- 项目例会：项目信息同步，问题卡点讨论，待办相关同步，这里的项目例会又包括常规项目例会和专项的项目例会，是项目管理中的信息渠道；
- 管理例会：团队仪式感必不可少的部分，除了事项的讨论，还有一个作用是发散的聊天，不用那么严肃，闲谈之中迸发一些火花，并达成一些共识和认知上的一致；
- 单独定期沟通会议：更私密一些的沟通会议，除了常规事项同步，更多的是一个散而不散的个人想法、规划、思路等的探讨；
- 复盘会议：对特定事项和问题的总结，讨论，属于常规会议机制的一种，起总结，沉淀的作用；
- OKR 会议：目标对齐，起方向对齐的作用；
- 需求规划会：有计划的对于需求进行规划，评审，然后进入迭代，开发测试并交付；
- 技术方案评审会：严格准入技术方案，集众人之力评估方案的可行性，看是否有什么缺漏。
着点讲一下周会，周会我们一般是指周例会，属于例行会议的一种，按周或双周召开。
周会的目的是根据会议的属性，定期回顾讨论总结指定的项，可能是专项，也可能是过程中的事项或突发的事情等。开会的目的主要是交流和讨论，那么在周会上我们讨论什么，在确定讨论内容之前，我们先看看哪些不要在周会上讨论：
- 紧急的事情不适合在周会讨论，出现的时候直接搞定；
- 非跨团队的问题不适合周会讨论；
- 纯执行细节问题不适合周会讨论；
- 大方向决策问题不适合周会讨论。
总结下来，就是涉及与会各团队的，对整体性计划或者需要协同配合的问题，或者里程碑式的改进型问题适合在周会上讨论。
当然，也不绝对，这还是一个人治的过程。
如果是你一个会议组织者，在组织一个会议的时候，需要考虑以下三件事：
- 这个会议最重要的事情是什么，是想解决什么问题？想讨论什么？
- 能否达到目标？ 大家对于目标是否有所了解？
- 如何达到目标？ 达到目标的关键路径是怎样的？干系人都在吗？
4 错误
工作中我们会出一些错误，生活中我们也会出一些错误，这些错误可能会影响同事朋友，或者影响线上产品，公司业务，甚至可能会造成个人或公司的经济损失，错误有其类型，在了解了这些类型后，我们可以适当的减少出错或规避这些错误。
从个人的角度来看，错误可分为成长之错，无心之错和性恶之错。
- 成长之错，我们都是从懵懂孩童，成长为有知识的学生，到长大成人，出来工作，工作中也是从不会到会，到熟练和精通，在这个过程中，正是因为一个个的错误，才成就了我们的成长，成长之错为正常之错，可允之；
- 无心之错，非有意为之的错误，一时失察导致工作出现错误，从而给别人带来不好的影响，或者粗心导致过错，其出发点都非有意，出错了就认，改过即可，不可连续；
- 性恶之错，以人性之恶为出发点或者动机，此种错不可原谅。
从工作的角度，错误可以分为超出型错误，信息型错误，粗心错误，态度型错误和风险型错误。
- 超出型错误，当你尝试去做能力之外挑战的时候，或者你不熟悉的领域或知识盲区，或者超出当前因为自身能力或其他条件的束缚，做得不够好而犯的错。比如一些新的想法的落地，一些新技术的试点等等，这些都没有人前人尝试过，至少在当前范围内没有，此时可能会遇到想象不到的坑，或者无法解决的问题，从而出现错误，甚至失误。这种创新或者超前的错误是可以接受的；
- 信息型错误，属于信息不对等，或者信息不全，知识不全面导致的错误，特别是对于工作中面对某个项目一些信息没有，或者没有去全面了解背景信息从而做出错误的决策，这种错误不会反复出现，但尽可能避免在不同类型的事情上犯同类型的错误；
- 粗心错误，这种比较常见，与无知错误不同，这种情况是你明明知道怎么回事，但是因为不小心或者忘记了而导致的错误，如果是粗心之人，可能会一错再错，此时需要反思自己，以某种方式规避；
- 态度型错误，指做事的态度有问题，比如眼看自己负责的一件事情要出问题或者已经出问题了，但是没有想办法去解决，没有付出努力，而是躺平，让事情自己变坏，甚至影响面不可控，这种错误是不允许的；
- 风险型错误，主动去做事情，但风险很高，是否会犯错不受自己的控制。比如你面临一个重要的选择，但在结果出来之前，你之前掌握的所有信息都无法告诉你哪个选择是绝对正确的，你只能去做自己认为是大概率的选择。而这种错误在工作中是极有可能遇到的。
对于工作中的错误我们应该如何减少或者规避呢？
- 超出型错误，从公司层面或者团队层面提供一些培训，或者在新人安排导师，提升大家的能力，或者通过流程机制让更有经验或者能力更强的人对于新的内容做一些把关；
- 信息型错误，信息型错误可以在公司层面搞定完善的文档和快捷的查询机制，任何技术或产品讨论以及达成的共识，要尽可能用某种沟通渠道发送到所有相关的人。让大尽可能的掌控更全面的信息；
- 粗心错误，设定一些机制来规避，如复盘机制，通过复盘，深挖过程中的问题，总结经验，为后续减少此类问题做准备，同时可以在流程上做一些 check 机制，通过多人的 check 减少错误的出现；
- 态度型错误，本着治病救人的态度先看看，如果实在不行，考虑换个人吧；
- 风险型错误，针对高风险的事情，尽可能的准备一个 PlanB，当事情没有按我们预想的方向发展时，启用 PlanB，减少损失，这也是我们下棋时通常会用到的策略，走一步，想三步。
从团队来看，一个人犯错，可能是人的问题，一群人犯错，一定是机制或系统出了问题。
当然，工作中我们允许试错，但是不能一错再错，避免一些不应该犯的错误，最大可能从错误中成长，这才是我们应有的态度。
除了以上，《清单革命》中说人类的错误可以分为两大类型。第一类是「无知之错」，我们犯错是因为没有掌握相关知识。第二类是「无能之错」，我们犯错并非因为没有掌握相关知识，而是因为没有正确使用这些知识。
现在，我们面临的错误更多的是「无能之错」，也就是如何持续、正确地运用我们所掌握的知识。「无知之错」可以原谅，「无能之错」不被原谅。
5 后记
管理是门实践的科学，大多数的书籍和文章都是个人或组织的经验之谈，没有公理，只能在俗世不断修行和精进，以求能「知行合一，止于至善」。
你好，我是潘锦，超过 10 年的研发管理和技术架构经历，出过书，创过业，带过百人团队，也在腾讯，A 股上市公司呆过一些年头，现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM，对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣，平时喜欢读书、思考，终身学习实践者，欢迎一起交流学习。微信公众号：架构和远方，博客： www.phppan.com
