系统健康度巡检
为什么要把系统健康度巡检放到技术管理里，我觉得这是一个非常重要的环节。像传统的航空、电力、汽车行业都要有一定的巡检机制，保障设备系统正常运转，同样软件系统也同样需要巡检机制保障业务健康发展。
随着业务的不断发展，业务量和数据量不断的上涨，系统架构的腐蚀是避免不了的，为了保障系统的健康度，需要不断的考虑对系统架构、性能进行优化。
系统的监控与报警能够一定程度发现系统存在的问题，系统存在的一些隐患需要通过对系统的巡检去发现，如果优化不及时在极端情况会导致故障，巡检粒度建议每周巡检一次自己所负责的业务系统。
系统巡检重点要关注如下几点：
系统指标：系统CPU、负载、内存、网络、磁盘有无异常情况波动，确认是否由发布导致，还是系统调用异常。
慢接口：通常rt大于3s的接口需要重点关注，极端并发场景下容易导致整个系统雪崩。
慢查询：MYSQL慢查询需要重点关注，随着数据量上涨，需要对慢查询进行优化。
错误日志：通过错误日志去发现系统隐藏的一些bug，避免这些bug被放大，甚至极端情况下会导致故障。
技术规划
技术规划通常由团队的TL负责，每个财年TL需要从大局的角度去思考每个季度的技术优化规划，去偿还技术债，技术债也是有利息的，因为利息的存在，技术债务不及时偿还的话，会在未来呈现出非线性增长，造成始料不及的损失。
这里的技术规划包括如下几点：
架构优化：一些结构不良、低内聚高耦合的代码则会使得哪怕是微小的需求变更或功能扩展都无从下手，修改的代价很可能超过了重写的代价。同样系统之间的耦合也需要重点去关注，遵循微服务化的原则，系统也要遵循单一职责原则，对于职责不清晰的系统去做解耦优化，进行一些模块化改造、服务隔离、公用服务抽象。
性能优化：基于财年对于业务量、数据量的发展评估，根据目前系统服务的QPSRT,需要提前规划对系统性能进行一些升级策略，包括重点关注对一些慢接口、慢查询的优化。
弹性与可靠性：系统提供的服务需要保障括数据一致性、幂等、防重攻击，同时也需要从熔断降级、异地多活的角度去考虑存在哪些问题，目前系统的SLA指标是否能够达到高可用，需要做哪些优化保障系统的高可用。
可伸缩：应用服务是否保证无状态，关键节点发生故障能够快速转移、扩容，避免故障扩大化。
大家不知道有没有类似的经历，某个时间段突然一些线上故障频发，各种技术债、业务债被业务方穷追猛打要求还债，如果出现这种现象很大程度这个TL已经失位了，这个团队失控了。也曾经有人跟我吐槽他的TL把活都分给他们，而TL自己什么都不干！这个技术TL真的什么都不干？曾经有一段时间我也在思考技术TL的核心职责到底是什么？技术TL应该具备哪些素质？
首先技术说到底是为业务服务的，除非技术就是业务本身，必须体现它的商业价值。在很多公司里技术研发真的就成了实现其他部门需求的工具，我觉得这样的技术TL肯定是不合格的。首先它不能影响业务发展，需求提出方会经过很多转化，如果不是不假思索传递需求，整个过程会失真。
第二个，我认为最最重要的是架构设计的能力，可能管理能力还次之。对于管理能力我认为最重要的是对团队的感知能力，因为一旦到了技术TL这个级别，不能脱离一线太远，业务细节可以不清楚，大的方向必须要明确。如果没有很细腻的感知能力，很多的决策会有偏差。
如果他不是一个业务架构师，不是一个能给团队指明更好方向的人，他最终会沦为一个需求翻译器，产品经理说怎么做就怎么做。他更多的只是负责保证产品的质量、开发的速度，最终被肢解成一个很琐碎的人。一旦团队上了一定的规模，团队就会从单纯的需求实现走向团队运营，而运营是需要方向的，业务架构就是一个基于运营和数据的一种综合的能力。
关于技术层面，技术TL需要具备如下素养：
技术视野良好，解决问题能力与架构设计能力出色。
技术TL要有良好的技术视野，不需要各种技术都样样精通，但是必须要所有涉猎，有所了解，对各种技术领域的发展趋势，主流非主流技术的应用场景要非常了解。知道在什么场景应用什么技术，业务发展到什么规模应该预先做哪些技术储备。产品架构的设计要有足够的弹性，既能够保证当前开发的高效率，又能够对未来产品架构的演进留出扩展的余地。
动手能力要强，学习能力出色。
技术TL并不需要自己亲自动手写代码，但是如有必要，自己可以随时动手参与第一线的编码工作，技术TL不能长期远离一线工作，自废武功，纸上谈兵。否则长此以往，会对技术的判断产生严重的失误。另外，技术TL也应该是一个学习能力非常出色的人，毕竟IT行业的技术更新换代速度非常快，如果没有快速学习能力，是没有资格做好技术TL的。
技术TL除了管人和管事之外，其他还有很多事情要做包括建立团队研发文化、团队人才培养与建设、跨部门协调与沟通等，这样以要求技术TL也同时也需要具备良好的沟通和管理能力。
联系我们
Contact us
战略解码