学会管理,成为会带团队的技术人

开篇词

技术人三要素:稳定性,债务,架构,技术管理要求是先技术,后管理。有哪些东西是作为技术leader必须要做好的本职工作,建立好自己的管理认知以及体系

稳定性

如何应对事故并做好复盘

82原则:20%人员能力和机制流程的欠缺,80%人员的稳定性意识不足,并且故障应对方法不当

稳定性KPI,事故类型,事故前预防,事故中应急,事故后复盘,总结经验

可用性事故,资损类事故,有条不紊的安排学生进行排障,确定信息沟通的秩序,结合信息做好线上同步

1-5-10标准,1分钟发现,5分钟响应,10分钟恢复,故障处理的核心在于快

故障处理的生命周期

发现异常,直接锁定+排除,比如刚发布了一个新功能,导致QPS下降,基本就可以断定是刚才发布的问题。当出现问题的时候,可能会有很多干扰因素,很难直接锁定,我们自己本身要做的就是结合业务场景,让链路上的所有关联方自查自证,通过排除法锁定故障,常见的应急三板斧,变更回滚,服务重启,降级&限流,注意紧急变更会不会引起新的风险

  1. 处理动作尽量简单,最好立竿见影
  2. 线上修复问题最忌讳因为赶时间就忽略关键测试,验证步骤,造成二次上线问题
  3. 除了修复系统的增量问题,故障数据也要处理,完全修复业务上的影响

如何有价值的做好事后的复盘:复盘的核心不是为了追责&甩锅,要最大程度的去榨干事故的剩余价值,通过全盘的思考与总结,来看看系统设计,流程机制,应急处理,人员安排等各方面有哪些不足,哪些可以提升的地方,哪些问题是共性的,需要在各个团队进行大扫除,一次学费,受益终身。

事故时长,事故根因,事故改进措施,事后复盘的时候,要详细介绍事故如何发生,如何处理,未来如何预防。如何带领团队把精力放在改进措施的落实以及事故前治理上,更有价值,需要留出时间让团队小伙伴进行内部review,避免为了开会而复盘

稳定性总结

可用性治理的三个关键要点

架构设计,编码,测试,上线。变更会引起90%以上的故障,小步快走,高速迭代。可监控,可回滚,可灰度。变更需要监控,完善的监控告警比人工反馈响应更快。要监控的内容:

  1. 是否有问题发生
  2. 哪里发生了问题
  3. 发生了什么问题

灰度就是为了对抗一些不确定性,并不是小范围测试,回滚就是变更的后悔药

验证演练预案设计,制造可控的故障

新人从稳定性学习开始,承诺一致性原则,学习最近半年的一个真实事故,并总结邮件给部门所有人

那些年源源不断的红包事故

平台感知能力弱,技术指标不敏感,持续时间长,资金损失大,问题难以第一时间恢复,止损后引起舆论事件和公关事件,感知难,修复慢,影响大

资损定义

  1. 防:人为配置,发放阶段,核销阶段,退回阶段。资金流,资金账户,资金计算,资金凭据
  2. 监:一致性与正确性双核对,业务监控,组合观察业务指标
  3. 控:资金拦截+资产控制。问题止血不新增,控制资金流出,存量数据订正

资损防控的关键

技术债务

技术债务是否已知,因为能力不足根本没有意识到债务的产生与积累,因为交付压力进而在技术方案与实现上妥协形成的已知的技术债务

主要以下几点:

  1. 开发者编写了低质量或者有潜在风险的代码
  2. 对于系统的实现和运行不了解,重复代码被大量的构造,缺少抽象与沉淀
  3. 缺少完善的开发机制和流程把控,比如测试,文档等方面做的不到位

交付压力导致技术妥协,导致迭代成本增加,没人能够清晰的讲明白现在的实现逻辑,隐藏bug风险性很大,居高不下,系统的扩展性以及系统迭代很困难,最终导致延期,恶性循环导致人员流失,旧系统问题很大却又没有很好的方式,沉重的技术债务,开发难度越来越大

如何带领团队从困境中突围

解决方式:

  1. 债务的Owner是技术leader,交付压力与技术债务的平衡,内外双修,增加减少债务的机会
  2. checklist识别债务,从看不到的技术债务到list,轻重缓急的区分,分期偿还技术债务,要逐渐减少
  3. 存在即合理,动态变化才是王道,逐渐减少。技术妥协换取更早的上线,在业务的发展中寻找平衡,适当的债务以及要适当的还款

大项目

一号工程(老板项目),技改项目(核心系统重写),倒排期的重大业务

跨部门沟通难,开会回报进度比写代码的时间还多,项目倒排期,开发资源压缩,结果评判标准不同,看最终业务目标

重构除了解决以前的问题,还要预防之后的问题,越是重大的项目,越要准备充足

把握关键点,谋定而后动

项目为什么要这么做,项目要做成什么样,哪些人要来做,项目启动之后要怎么做,每部分要有负责人,各部分周期越短越好,可验证,立项会议

  1. 缺兵少将,以项目的价值与收益为本金,借助上级组织的力量从其它团队借人。从更大的范围找人,项目交付并不等于结束
  2. 推不动的是人还是事。搞明白冲突现象下的利益诉求,为项目结果适当妥协,拖过项目地位和决策机制推动项目
  3. 一定会有项目变更,项目演进过程中识别出之前未考虑到的点。优先级排期,加班,统一变更统一管理,多汇报,了解当前的风险点

驾驭大项目,人的问题要多余技术问题,按时上线,更关键的是业务效果以及对应的业务结果

业务理解

大项目管理,结构设计以及对应的业务场景来进行对应的设计,理解业务这件事

深入业务

产品需求不等于业务诉求,理解业务需求,整个业务流程:用户真实需求->业务->运营->产品->技术,中间经过了不断的加工处理以及拆分,要搞清楚源头。不能成为工具人,要明白自己的团队要干啥,但是不仅仅局限于团队干啥。

要清楚业务的现状,推测业务的发展,思考业务上对应的诉求,深度理解业务要成为前提,提升技术团队的使命感,实际体验客诉,并通过自己写的代码解决让客服&用户头疼的问题,体现自己的价值,你会发现你是在帮助他人解决问题而不仅仅只是写代码。

如何理解业务:

  1. 不要盲信产品,永远不要试图用战术上的勤奋,去掩盖你战略上的懒惰
  2. 从业务方接受需求描述说明-简单加工成PRD-根据业务方嗓门大小进行优先级排序-直接输出给技术,要学会独立思考,深入理解业务要解决什么问题,需要什么效果或者什么作用,严格把控那些伪需求和无价值需求,防止他们侵占团队的技术资源,防止PM成为传话筒
  3. 代入用户视角,实际体验一下,建立走进业务的机制,代入感,不要一次性作秀
  4. 分享业务对应的流程,借助数据变化,了解深入,业务与编码同样重要

深刻理解业务

架构设计

架构工作的核心关注点,功能实现,性能优化,稳定性。接手历史系统,处理问题,结构性上没有设计好。重构系统,高扩展

  1. 理解成本高
  2. 变更牵连多
  3. 一张图装不下
  4. 加人也无法解决问题,复杂度高,迭代压力大,稳定性频发

治理好系统复杂度才最务实

高内聚,低耦合,去掉不必要的复杂,分治,拆分到可解决的粒度,没有什么问题是拆模块解决不了的,如果有,就再拆一层,要适当的拆分,垂直拆分:把差异明确可以独立迭代的业务拆分开。水平拆分:把共性的能力下沉隔离。拆分与合并不决定

  1. 更重注设计,对于coding来说
  2. 永远做2套以上的方案
  3. 从mvp的视角考虑设计,先做减法再做加法
  4. 关注上下游的实现
  5. 坚持日拱一卒,尽可能在每次迭代的过程中修复一个小问题
  6. 通过技术的建设让技术走在业务前面