图片
技术治理结果的好坏往往体现在系统稳定性、研发效率、IT成本这三个方面，过去3年时间里，我和我的团队一直在做这三方面的事情，从现在的结果看：
接下来我会介绍我们的实践路径，以及遇到的关键挑战和应对措施，希望本次分享可以给正在从事这项领域事情的朋友带来一些参考价值。
图片
从20年开始到现在，我们的业务订单规模从大约50w/天发展到现在远远超过100w/天，技术团队规模也从300+人增长到现如今的1000+人，在这3～4年时间里，技术治理在不同时间阶段也采取了不同的处理方式：
接下来，我会从基础架构演进、稳定性保障和IT成本治理这三个方面分享下团队过去几年里的实践总结，尤其是关键技术方案选型、取舍的背后思考逻辑，和一些建议。
图片
基础架构的演进需要遵循最优满足业务核心诉求原则，随着互联网行业技术的发展沉淀，现在技术架构的实现与落地的门槛越来越低，架构师比较容易设计和交付出先进的技术架构方案和方案落地规划，但先进的技术架构不一定是业务核心诉求的最优解。我们演进基础架构主要遵循两个思考点，作为背后的驱动力：
「领先业务“半步”，不过度演进」是我们对演进节奏的把控，从2019年以“多个大单体服务架构”演进到2023年的“多泳道架构”，每一次的架构升级都是做增量设计，对现有运行时环境、中间件进行改造，几乎不会对业务研发产生影响，也不需要业务研发投入大量时间配合改造。同时，每一次架构升级都很好的解决了当期的核心痛点：
图片
依据实践经历，有三个方面是我们格外注意的：
因为基础技术架构本质是由一组技术规则构成，规则从流量调度、请求路由、服务调用、数据读写等多方面进行了约束，且不能被打破，它天生就造成对业务技术架构的侵入，影响了灵活性，所以好的基础架构尽可能减少对上层应用的侵入是非常重要的；此外，选择团队和业务研发同学他们最熟悉的技术通常是最优的选择，不要过于追求先进技术。
我们早期的系统是由多个内部PHP服务（服务臃肿，单个core服务包含几百个接口很常见）组成，内部服务之间主要通过域名+HTTP方式相互通讯，服务间通讯没有标准的数据协议规范、缺乏基本的服务治理能力。随着业务规模增长和系统整体复杂度上升，我们决定向微服务架构演进，就遇到了要么一刀切大规模改造、要么缓慢治理的选择问题：
最终，我们选择了semi-SOA的方案（一种类似于半服务化思路、内部我们称呼为泛服务调用），通过semi-SOA让新老PHP服务、以及新老Java服务之间可以方面的互通互联，同时整体系统又具备服务化治理能力，最重要的是所有业务研发团队不需要立即参入大规模改造，这种“过渡型技术方案”给研发团队预留了充足的按需改造时间，有条件的业务研发团队可以先行改造，去PHP化，新的Java服务与现存PHP服务之间又可以很好的兼容。
图片
我们大约每间隔1年时间都会进行一轮基础架构的演进迭代，一方面是为长期大方向做一些储备，另一方面是仅解决短期即将遇见的需求问题，2023年进入多泳道架构（一种跨AZ的高可用架构），驱动我们做这件事情主要有两个方面：
并未将基础架构直接演进到同城双活，主要是考虑成本，一方面IT资源成本，另一方面是研发改造成本；另外就是单AZ机房环境下系统稳定性还有很多提升的空间，我们认为这样的“保险”程度目前是最合宜的。
图片
做好技术保障，防范系统稳定性风险的发生是技术治理过程中一个重要目标，过去4年时间里，我们的稳定性保障经历了三个阶段，每个阶段都制定了差异化的核心建设，通过阶段性的迭代达到目前的体系化，系统故障数量从阶段一时期的不理想状态慢慢稳定下来，到目前达到了健康状态。
早期阶段，我们更重视基本能力的建设，也就是守住关键战场的基本盘能稳定性下来，早期的监控告警平台、限流降级工具、生产环境变更规范都是需要重视的战场。
当整体稳定下来后，所有工程师在日常系统变更、服务上线都有了稳定性意识，大家都在按照统一的规范进行操作，遇到问题都会按照规范进行应急处理了。接下来阶段二我们会更关注效率和精细化的提升，我们成立了全职NOC团队专门对系统进行盯盘和检测、第一时间启动应急，也补齐了像容量压测等工具平台的建设，进行深度的业务服务链路风险的治理。这个阶段，应急处理效率、故障止损时效都有了具体的提升。
最终，我们的焦点是如何保障长期不出故障，尽可能防范黑天鹅和灰犀牛事件的发生。这个时期，除了工具能力、规范体系的不断完善外，会更加重视稳定性保障项目的日常运营，一些简单的事情会重复反复的去做，坚持高质量的去做（譬如：每天都会对当日发生的隐患事件进行复盘，渴望发生共性问题，从而反哺回进一步优化工具和体系）
图片
回顾我们整个稳定性保障的经历，无论是早期的搭建工具能力、完善规范，还是中后期建制度和保障体系，都不是一帆风顺，也经常遇到因服务雪崩导致故障止血不及时、忘记设置告警导致不能早起发现问题、共性的隐患在服务链路上未治理彻底或重新滋生导致故障等等，我们总结有三个关键地方需要格外做好：
1）保持极大的耐心，持续的高质量做好日常“重复性”的事情，譬如链路服务的梳理和治理我们会间隔半年时间就会重复做一次，除了维护业务链路架构和理性外，也解决过去半年新引入的问题；在日常发生的稳定性隐患事件（非故障或冒烟）后，也会在当日就闭环复盘，找出隐患发生的根因，举一反三；
2）稳定性保障最大的挑战之一就是效率，长期始终如一的投入很多研发时间到稳定性上是很难的，所以凡事能提升研发在稳定性保障上的效率非常重要。模板告警是我们过去设计的一种智能告警的工具功能，它非常有用，我们将服务运行时状态中通用的地方（譬如：服务某种类型的异常数量同环比波动超过30%）都支持了模板告警，无需研发主动配置告警，即节省了研发大量时间，也避免了研发漏配或错配；
3）如何长期获得一个好结果（不发生故障）是我们追求的终极目标，除了在技术上、人员素质上要持续提升外，我们认为有2个理念非常重要：
稳定性日常运营
图片
最后想和大家聊一下「稳定性日常运营」在我们的实践中起到的巨大作用。
稳定性规范和应急能力随着规模增长、系统复杂度上升后是需要重新迭代的，迭代的方向和内容是依靠日常运营中不断的收集和统计，譬如NOC团队会收集每一天发生的所有隐患事件并给事件打上各种标签，每个月都会分析它们，会尝试发现是否有异常的标签类型，并反馈给工具团队或者SOP规范定义团队进行优化。
日常运营也有多种运营级别，当系统、团队、日常趋势状态都比较平稳的时候，运营级别是最低档的，最低档运营级别对投入的要求最小，当趋势状态糟糕时会调升运营级别，这是一种灵活的方式来平衡稳定性保障与研发投入的做法，当然日常运营的方式方法非常多，这里不做详细展开了。
总结下，日常运营可以帮助我们持续发现更多的瑕疵和漏洞，并反哺回规范机制与工具能力，运营内容涉及到规范、演练、技术治理、文化考试等多方面，它有效的防范了大家长期做一件事情的过程中容易导致的疏忽、犯错风险。
图片
最近几年，大家都在做降本增效，IT资源成本是大头。我们过去2年把IT单均数值优化下降了50%以上，主要有两个原因：首先最重要是早期业务快速发展时期，我们对IT资源使用效率关注是不够的，所以在调整使用方式、做一些基本的技术优化后就有了明显的提升；另外就是建立起资源使用规范（包括不限于：资源分摊、预算管理、成本可视化、成本异常检测等等），杜绝不合理资源使用的产生。
其实，IT成本治理的关键点是IT资源是否做到了很高程度的科学使用，资源效率是不是达到了健康水平，唯省钱目的是不对的，这可能会对业务发展带来损害，如果取得了IT成本治理结果而导致稳定性风险或者研发效率大大降低，那这样是不划算的，大家根据自己公司业务发展情况平衡看待吧。
图片
我们在IT成本治理过程中，也发现了很多有意思的地方经验技巧，比方说你可以联合公司采购团队去和供应商重新谈判，尝试争取更优惠的商务折扣，往往会立竿见影。
上图，是我们进行IT成本治理优化的方法矩阵，矩阵中的“降低价格/价”就非常管用，我们对不同业务模块的资源采取合理的RI(1/3年)、Savingplan、Spot/Ondemand等购买方式可以极大降低资源购买成本；其余优化方法措施不进行详细介绍了，大家可以自行查阅。
陈永庭，货拉拉 技术总监。货拉拉技术中心核心基础设施部(CI)负责人，带领CI团队负责公司整体基础架构的演进，填补、维护基础技术能力（中间件、框架、工具）保障技术团队的研发效率，负责全局稳定性和技术保障、资源交付和IT成本治理优化等主要工作。曾就职饿了么、腾讯、WebEx/Cisco，主要专注于中间件和基础服务的研发、异地多活架构的设计与实施落地。（联系邮箱：sam1.chen@huolala.cn）
本文链接：http://www.28at.com/showinfo-26-62361-0.htmlIT降本50%还贼稳！百万订单规模系统的技术治理实践
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 快速在你的Vue/React应用中实现SSR(服务端渲染)
下一篇： 三分钟带你搞懂 Future 玩法
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
