如何开始开展技术优化

通常我们在说技术架构时，一般是指技术架构的演进，而技术架构的演进就是对现存技术体系的优化提升工作。所有的技术架构优化活动的根本目的都是降本提效、提升用户体验，所以我们讨论的问题可归结为如何做才能更接近我们架构活动的目的。

不谋万世者，不足谋一时；不谋全局者，不足谋一域

体系化的认知

在做任何技术优化工作的统筹规划之前，都建议对相关的知识有一个体系化的认知，包含业务、技术、管理等方方面面。建立认知体系必须是自上而下的，从框架开始搭建逻辑脉络，再自下而上的积累知识，填充血肉。

看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水

这几句话分别对应着三个境界：经验、方法、原理；但认知要多几层，可以大致上分为几个：

• 信息，多数的信息是无价值的，只有少数有价值的信息才会变成经验
• 经验，看山是山，看水是水；只能通过别人教导或观察别人解决问题。换一个问题就无法自行解决
• 方法，看山不是山，看水不是水；开始寻找解决不同问题的方法
• 原理，看山还是山，看水还是水；看透山水的原理，只要是山，就可以用山的原理来解决问题。也就是已经建立方法论，可以针对已知的、未知的情况使用或创造新的方法
• 哲学，也就是常常听到的“智慧”、“思维”，它可以指导如何运用知识。具备这一层认知可以发现事物的本质，即就是事物遵循的原理、规则，再利用该原理相应的方法来解决问题
• 自我，指导会把知识用在何处，以及与外部环境产生的利害关系

我们常听到认知有差距，不同认知水平的人通常是无法交流的，要不对方无法理解你的意思，要不对方觉得你讲的太肤浅，所以我们要让参与的人有同样的认知水平。大多数人只能意识到高一层的认知，再高一层就会觉得很虚。虚还是实取决于能不能理解和利用起来解决实际的、现实的问题，随着认知的提高，渔也会变成鱼，高层次认知看低层次认知会有一种看“瞎子”的感觉，容易陷入“知识的诅咒”。

跨层次认知需要突破，同层次认知需要积累。积累不必然可以突破，但突破必须依靠积累。

事情的重要性

依据时间管理理论中的一个重要方法：四象限法则；所有的事情都分轻重缓急，我们需要有重点地把主要的精力和时间集中地放在那些重要但不紧急的工作上，这样可以做到未雨绸缪，防患未然。

1. 第一象限，这个象限的事情具有时间的紧迫性和影响的重要性，无法回避也不能拖延，必须要优先解决的特性。研发上的体现如线上服务的崩溃、付费注册等关键环节的异常等
2. 第二象限，这类事情通常有很大的欺骗性。很多人有认为紧急的事情都是重要的这个误区，如打麻将三缺一等。所以要注意与第一象限的事情做区分
3. 第三象限，这类事情大多都是琐碎的杂事，没有时间的紧迫性
4. 第四象限，这个象限中的事情往往没有时间上的紧迫性，但是有很重大的影响，对于团队、个人、企业的发展及环境的建立与维护有重大意义的

在技术工作中，我们首先应当优先解决重要且紧急的处于第一象限的事情，这类事情关系着现有服务或流程的稳定性，如果这些事情都无法得到妥善的处理，那就没有处理处于其他象限的事情的必要了。

技术优化工作与正常的技术迭代工作有很大的不同，技术迭代工作更多的关注点在于需求的实现，但优化工作的关注点在于流程的改造、效率的提高、成本的减少。在技术优化工作中，我们应当从第四象限中重要但不紧急的事情中选择。这些事情很重要，且有充足的时间去准备、有充足的时间去做好，我们选择这类事情的原因是 它的回报是最大的。

风险的影响面

第二点需要注意的是风险的影响面，主要有三方面：

1. 对业务运行造成的不良影响，这个很好理解，指的就是在技术优化工作执行过程中对现有业务运行造成的影响，如付费功能的异常、注册用户数降低、页面PV降低了等等诸如此类的问题，更严重的可能直接影响了正常的运行，甚至数据的错误，这类影响往往是不可逆的，影响时非常严重的。

   所以，在技术优化工作的前期规划中就要着重考虑这方面，制定消除或尽量避免该类影响的方案。

2. 对团队成员的不利影响，这个主要是管理上存在的一定风险，发生的概率私以为还是比较低的。大多数开发人员对新事物的接纳程度还是比较高的，可作为次要风险来考虑。

3. 对执行过程中的不确定的容错或兼容机制，技术实施过程中往往伴随着种种不确定性，我们在对优化工作的风险评估时还要增加对这些不确定性的容错或兼容机制是否充足的评判。

合理性的评判

另外一个重中之重要考虑的就是对合理性的评判，包含技术的合理性与成本的合理性。

1. 技术合理性

技术的世界中没有最优化，只有最合适，技术始终以高效、稳定、安全为目标来衡量合理性。技术优化的本质就是解决复杂度带来的问题，复杂度表现为多种，如业务复杂度、性能复杂度、可用性可扩展复杂度、安全复杂度等，那如何评判技术的合理性：

• 需求角度，这个角度又可以分为三个层次：

  • 能解决当下的需求与问题
  • 能高效的完成需求，解决问题，即能优雅且可复用的方式解决当下所有的问题
  • 前瞻性设计，在未来一段时间都可以以第二层次的方式满足需求，从而不会每次当业务进行演变时，导致天翻地覆的结构性变化

• 非需求角度，主要是对指标影响的评估，可主要分为以下几点：

  • 稳定性指标，即高可用
  • 高效指标，即文档化、可扩展与复用性。设计时应该秉承着低耦合的理念去做，同时做好避免重复劳动的复用性设计
  • 安全指标，执行过程中产生的数据或通信方式的安全性考虑，如加密、HTTPS等

2. 成本合理性

在做技术优化之前要考虑到优化工作的人力、时间成本，即要尽量做到人效的合理。

对成本的合理性评判主要是看技术优化预期可带来的价值能不能与预期要付出的人力与时间相匹配，另外也要考虑所能获取到的人力与时间。执行过程中往往是可提供的人力较少，这种情况需要更多的时间；提供的时间成本少，则人力需求就更大一些，人力与时间的成本消耗是此消彼长的。

环境的适配性

除了上述几点外，也需要考虑执行中与执行后的环境适配性，可分为流程兼容性与团队的可控性：

1. 流程兼容性，技术优化工作对现有团队已经形成的研发、审核、发布部署等流程造成的冲击，是否会影响这些已有流程的正常运作，对这些流程是否有颠覆性的改变也是我们前期预演阶段需要重点关注的。这些流程都关系着效率的保证，一旦不能正常运作，效率就会大打折扣，进而影响到研发交付。

2. 团队可控性，这里指的是团队对技术的可控性。技术优化工作中通常表现为因为达到更大的价值或者更有的解决方案而引入的新技术团队中有没有多人掌握，或者这项技术是否可以通过培训快速掌握；如果不能，团队则失去了对技术的可控性，这将是无比危险的，意味着发成异常问题时，团队中只有极个别人可能有解决能力。

   我们应该尽量避免这种情况的发生，所以通常情况下我们应该使用成熟的几十方案，要有活跃的社区，完备的文档，大量的参考资料；这样团队成员进行学习与解决问题时有更多的途径与渠道，有利于技术的推广与人员的成长。

准备事后复盘

除了上述几点外，如何开展技术优化工作还可能涉及到任务边界的划分、完整性核对、是否有阶段性里程碑等更多方面知识。

但这里还需要再提一个执行后非常重要的点：复盘。在优化工作执行完成后，非常建议做有价值的复盘，这种复盘指的是通过还原并深度思考优化活动的完整历程，来寻找可以提升未来技术活动的成功概率的过程。复盘的对象不应只包含失败的案例，更应该包含成功的案例，我们通常对成功的案例有着更加主动的学习动机，即就是路径依赖。这里列举几个复盘活动中常见的误区：

1. 止于问责。问责机制的确定可以用于复盘环节中，来帮助发现问题的真正根因，但找到活惩罚责任人并不是复盘的目标，也不应该是复盘的重点，复盘的目标是寻找可以提成未来成功概率的机会点。问责制通常有偏离目标、人才流失等缺陷：
   • 偏离目标，问责制会导致复盘时大量的时间都耗费在问责的过程中，甚至就是在讨论“谁的责任更大一些”的问题。
   • 遗留隐患，问责处罚完后，隐患并不会消除，反而会导致隐患被完全忽视。
   • 人才流失，高风险的项目本来就容易失败，一旦斩了先锋，可能再也没有人敢为人先了。
2. 止于意识提升，在复盘过程中，肯定会涉及自我剖析，寻找各自的提升点。但是复盘更重要的是团队或公司等整体的能力提升。
3. 止于错误补救。更准确的说是在最大程度上挽回问题所造成的损失，这是对已经完成的活动的补充，是个收尾动作，并不能对未来的优化活动形成任何助力。

P.S. 以上的论述受限于目前的认知体系，可能有失偏颇，不必纠结对错与否，仅参考对自己有收获的即可。