一、背景介绍　　

　　技术治理结果的好坏往往体现在系统稳定性、研发效率、IT成本这三个方面，过去3年时间里，我和我的团队一直在做这三方面的事情，从现在的结果看：

　　系统稳定性从早期的故障频发到如今故障收敛，并已经接近2年都未发生过严重故障；

　　IT单均（每笔订单的IT花费）过去一年也下降了50%以上，看起来是挺有效果的。

　　接下来我会介绍我们的实践路径，以及遇到的关键挑战和应对措施，希望本次分享可以给正在从事这项领域事情的朋友带来一些参考价值。　　

　　从20年开始到现在，我们的业务订单规模从大约50w/天发展到现在远远超过100w/天，技术团队规模也从300+人增长到现如今的1000+人，在这3～4年时间里，技术治理在不同时间阶段也采取了不同的处理方式：

　　早期我们会更侧重于对研发效率的提升，尽最大可能提升研发项目的迭代效率，支撑业务快速的发展。长期未得到妥善解决的技术债会加剧系统稳定性风险，我们就会切换治理重点，通过演进和改造基础架构来提升系统高可用性，复杂的基础架构势，必会引入更多的架构规则约束，也会影响到研发效率，这个我们是可以接受的；

　　早期业务高速发展时期，更倾向于通过叠加IT资源，来加速技术迭代效率和守护技术稳定性，一般中后期我们就会遇到IT成本的压力，所以也需要更多的关注IT资源的使用效率，技术治理中提高IT资源优化的权重。长期的技术治理过程中，我们很难同时满足三个方面，以最大化支持公司业务发展考虑，在一些“平衡点”前后需要做一些侧重点的切换。

　　接下来，我会从基础架构演进、稳定性保障和IT成本治理这三个方面分享下团队过去几年里的实践总结，尤其是关键技术方案选型、取舍的背后思考逻辑，和一些建议。

　　二、基础架构的演进　　

　　基础架构的演进需要遵循最优满足业务核心诉求原则，随着互联网行业技术的发展沉淀，现在技术架构的实现与落地的门槛越来越低，架构师比较容易设计和交付出先进的技术架构方案和方案落地规划，但先进的技术架构不一定是业务核心诉求的更优解。我们演进基础架构主要遵循两个思考点，作为背后的驱动力：

　　技术支撑业务快速发展，对研发效率和稳定性的诉求，即技术要快又稳

　　研发效率和稳定性对基础架构的要求

　　「领先业务“半步”，不过度演进」是我们对演进节奏的把控，从2019年以“多个大单体服务架构”演进到2023年的“多泳道架构”，每一次的架构升级都是做增量设计，对现有运行时环境、中间件进行改造，几乎不会对业务研发产生影响，也不需要业务研发投入大量时间配合改造。同时，每一次架构升级都很好的解决了当期的核心痛点：

　　2020年，基础架构由PHP单体大服务升级到泛服务化架构，解决了业务研发对服务化治理的诉求，也无需进行大规模的老代码重构；

　　2021年，在微服务架构基础上支持全链路灰度能力，支持全链路灰度高峰期发布，一个物理环境轻易就能快速构建出多个独立的逻辑链路环境，解决了研发和测试同学当期的工作效率问题；

　　2023年，在全链路灰度架构基础上对流量标识、网关、数据存储等进行改造，演进到多泳道架构，单个泳道对应单个物理AZ，一个请求的后端事务处理尽可能在单泳道内闭环，支持AZ机房容灾容错能力。　　

　　依据实践经历，有三个方面是我们格外注意的：

　　尽可能对上层服务、应用架构不侵入

　　尽可能不造成业务研发大面积的配合改造

　　团队熟悉的技术

　　因为基础技术架构本质是由一组技术规则构成，规则从流量调度、请求路由、服务调用、数据读写等多方面进行了约束，且不能被打破，它天生就造成对业务技术架构的侵入，影响了灵活性，所以好的基础架构尽可能减少对上层应用的侵入是非常重要的；此外，选择团队和业务研发同学他们最熟悉的技术通常是最优的选择，不要过于追求先进技术。

　　我们早期的系统是由多个内部PHP服务（服务臃肿，单个core服务包含几百个接口很常见）组成，内部服务之间主要通过域名+HTTP方式相互通讯，服务间通讯没有标准的数据协议规范、缺乏基本的服务治理能力。随着业务规模增长和系统整体复杂度上升，我们决定向微服务架构演进，就遇到了要么一刀切大规模改造、要么缓慢治理的选择问题：

　　一刀切：采取成熟的开源SOA框架（像SpringCloud或dubbo），直接把我们的PHP服务按照SOA规范改造成标准SOA服务。这个思路的最大问题是影响面广，涉及到每一个团队，改造工作量巨大，改造周期会比较长，可能会影响正常业务需求的日常交付上线，对处于高速发展期的业务来说难以接受；

　　semi-SOA：避免一刀切，研发可以根据自身情况按需择时重构，先初步具备服务治理能力。

　　最终，我们选择了semi-SOA的方案（一种类似于半服务化思路、内部我们称呼为泛服务调用），通过semi-SOA让新老PHP服务、以及新老Java服务之间可以方面的互通互联，同时整体系统又具备服务化治理能力，最重要的是所有业务研发团队不需要立即参入大规模改造，这种“过渡型技术方案”给研发团队预留了充足的按需改造时间，有条件的业务研发团队可以先行改造，去PHP化，新的Java服务与现存PHP服务之间又可以很好的兼容。　　

　　我们大约每间隔1年时间都会进行一轮基础架构的演进迭代，一方面是为长期大方向做一些储备，另一方面是仅解决短期即将遇见的需求问题，2023年进入多泳道架构（一种跨AZ的高可用架构），驱动我们做这件事情主要有两个方面：

　　业务发展诉求，即是系统稳定性要求，2022.4我们就发生过因底层硬件变更引发150台机架宕机故障，我们业务系统瘫痪且无法恢复，只能等厂商修复；

　　业务对系统故障容忍度降低了，系统不可用导致的业务损失比较大了，需要我们考虑为这种低频事件买一份“保险”，做更多的投入。

　　并未将基础架构直接演进到同城双活，主要是考虑成本，一方面IT资源成本，另一方面是研发改造成本；另外就是单AZ机房环境下系统稳定性还有很多提升的空间，我们认为这样的“保险”程度目前是最合宜的。

　　三、技术保障的取舍　　

　　做好技术保障，防范系统稳定性风险的发生是技术治理过程中一个重要目标，过去4年时间里，我们的稳定性保障经历了三个阶段，每个阶段都制定了差异化的核心建设，通过阶段性的迭代达到目前的体系化，系统故障数量从阶段一时期的不理想状态慢慢稳定下来，到目前达到了健康状态。

　　阶段一：活下来

　　早期阶段，我们更重视基本能力的建设，也就是守住关键战场的基本盘能稳定性下来，早期的监控告警平台、限流降级工具、生产环境变更规范都是需要重视的战场。

　　阶段二：规范、工具建设

　　当整体稳定下来后，所有工程师在日常系统变更、服务上线都有了稳定性意识，大家都在按照统一的规范进行操作，遇到问题都会按照规范进行应急处理了。接下来阶段二我们会更关注效率和精细化的提升，我们成立了全职NOC团队专门对系统进行盯盘和检测、第一时间启动应急，也补齐了像容量压测等工具平台的建设，进行深度的业务服务链路风险的治理。这个阶段，应急处理效率、故障止损时效都有了具体的提升。

　　阶段三：体系化建设

　　最终，我们的焦点是如何保障长期不出故障，尽可能防范黑天鹅和灰犀牛事件的发生。这个时期，除了工具能力、规范体系的不断完善外，会更加重视稳定性保障项目的日常运营，一些简单的事情会重复反复的去做，坚持高质量的去做（譬如：每天都会对当日发生的隐患事件进行复盘，渴望发生共性问题，从而反哺回进一步优化工具和体系）　　

　　回顾我们整个稳定性保障的经历，无论是早期的搭建工具能力、完善规范，还是中后期建制度和保障体系，都不是一帆风顺，也经常遇到因服务雪崩导致故障止血不及时、忘记设置告警导致不能早起发现问题、共性的隐患在服务链路上未治理彻底或重新滋生导致故障等等，我们总结有三个关键地方需要格外做好：

　　1）保持极大的耐心，持续的高质量做好日常“重复性”的事情，譬如链路服务的梳理和治理我们会间隔半年时间就会重复做一次，除了维护业务链路架构和理性外，也解决过去半年新引入的问题；在日常发生的稳定性隐患事件（非故障或冒烟）后，也会在当日就闭环复盘，找出隐患发生的根因，举一反三；

　　2）稳定性保障最大的挑战之一就是效率，长期始终如一的投入很多研发时间到稳定性上是很难的，所以凡事能提升研发在稳定性保障上的效率非常重要。模板告警是我们过去设计的一种智能告警的工具功能，它非常有用，我们将服务运行时状态中通用的地方（譬如：服务某种类型的异常数量同环比波动超过30%）都支持了模板告警，无需研发主动配置告警，即节省了研发大量时间，也避免了研发漏配或错配；

　　3）如何长期获得一个好结果（不发生故障）是我们追求的终极目标，除了在技术上、人员素质上要持续提升外，我们认为有2个理念非常重要：

　　规范体系需要具备自我迭代能力，过去定义的规范不一定最适配当下，所以我们每次在事件复盘中都渴望发现一些整改代办项，完善当前的规范体系；

　　不仅仅要做应急预案的技术功能性演练，其他任何预期性质的SOP都尽可能开展演练，把演练变成日常的一种习惯，这样才能尽可能保证当发生非预期事件（故障、冒烟）时你的所有预期内的工具、SOP都能正常表现

　　稳定性日常运营　　

　　最后想和大家聊一下「稳定性日常运营」在我们的实践中起到的巨大作用。

　　稳定性规范和应急能力随着规模增长、系统复杂度上升后是需要重新迭代的，迭代的方向和内容是依靠日常运营中不断的收集和统计，譬如NOC团队会收集每一天发生的所有隐患事件并给事件打上各种标签，每个月都会分析它们，会尝试发现是否有异常的标签类型，并反馈给工具团队或者SOP规范定义团队进行优化。

　　日常运营也有多种运营级别，当系统、团队、日常趋势状态都比较平稳的时候，运营级别是最低档的，最低档运营级别对投入的要求最小，当趋势状态糟糕时会调升运营级别，这是一种灵活的方式来平衡稳定性保障与研发投入的做法，当然日常运营的方式方法非常多，这里不做详细展开了。

　　总结下，日常运营可以帮助我们持续发现更多的瑕疵和漏洞，并反哺回规范机制与工具能力，运营内容涉及到规范、演练、技术治理、文化考试等多方面，它有效的防范了大家长期做一件事情的过程中容易导致的疏忽、犯错风险。

　　四、IT成本如何管治　　

　　最近几年，大家都在做降本增效，IT资源成本是大头。我们过去2年把IT单均数值优化下降了50%以上，主要有两个原因：首先最重要是早期业务快速发展时期，我们对IT资源使用效率关注是不够的，所以在调整使用方式、做一些基本的技术优化后就有了明显的提升；另外就是建立起资源使用规范（包括不限于：资源分摊、预算管理、成本可视化、成本异常检测等等），杜绝不合理资源使用的产生。

　　其实，IT成本治理的关键点是IT资源是否做到了很高程度的科学使用，资源效率是不是达到了健康水平，唯省钱目的是不对的，这可能会对业务发展带来损害，如果取得了IT成本治理结果而导致稳定性风险或者研发效率大大降低，那这样是不划算的，大家根据自己公司业务发展情况平衡看待吧。　　

　　我们在IT成本治理过程中，也发现了很多有意思的地方经验技巧，比方说你可以联合公司采购团队去和供应商重新谈判，尝试争取更优惠的商务折扣，往往会立竿见影。

　　上图，是我们进行IT成本治理优化的方法矩阵，矩阵中的“降低价格/价”就非常管用，我们对不同业务模块的资源采取合理的RI(1/3年)、Savingplan、Spot/Ondemand等购买方式可以极大降低资源购买成本；其余优化方法措施不进行详细介绍了，大家可以自行查阅。