运维建设的一些思考

导读

本文将断续、松散的记录,楼主在运维管理和工作实施中的一些思考。

2020.08.14 大规范小规范

规范有大小。大规范一般画出一个轮廓,能给出指导意义;具体落地则需要SRE的个人来执行(小规范)。 SRE个体习惯有差异,对小规范认知不一致,最后可能伤害到大规范的落地效果。这就像开发团队的代码风格治理一样,在小规范实施时,要有机制、拉平SRE的习惯认知。

2020.08.01 运维产出的思考

运维工作往往融合了 “技术+事务” 两个特色。事务性工作产出制度流程范式,使新人可以按图索骥、并以叠加式改进。技术性工作产出平台设计,以平台的方式沉淀运维能力(最佳实践)。

2020.07.23 做稳定性规划的一些感受

之前一般按照故障处理模型,来做稳定性规划。今年尝试从”对象+方向”双维度来做,效果还不错。一些小的感受如下,

  • 预案属于强业务场景,适合按场景闭环、不适合作为一个专项来做
  • 容量场景化较弱,适合横向展开。这根涉及容量的场景比较少有关

2020.07.19 领导团队的关键点

领导团队的关键点有:看方向,带人,做事。最近一年,在带人、做事方面都算过关,但在看方向上做的较差。 要么主动思考、要么被安排,方向大事容不得一丝懈怠。

2020.07.18 刻意练习不能丢

最近半年借口太忙,在刻意练习上投入的很少,导致能力体系进步较少。 回想一路走来,每次实质性突破都有刻意练习的影子。定个小计划,后续每周留2-5个小时做刻意练习,加班很关键。

2020.04.15 工具是最好的协作者

工具是运维最佳实践的有效载体,最终都能进化为用户友好的形态。 从这个意义上讲,工具可以协助降低对从业人员的服务心态要求。在工具达到一定能力之前,所谓的服务心态很难维系。

2020.04.01 传统Ops和SRE主要区别

Ops倾向于被动执行,而SRE倾向于主动思考

2020.03.25 关于分阶段交付

人力有限时,大项目往往要分阶段交付,每个阶段交付1+个相对独立的产品功能。

Dev同学可能对分阶段认识有误区,可能会站在技术或代码开发的角度来分阶段,导致无法持续交付产品功能。这一点需要关注。

2020.03.15 一线同事能力较差时,如何保证结果质量

由于历史原因,团队会留下了一些能力较差的一线同事,且主动/被动进化的效果不理想。为了利用这一部分人力,同时达成高质量的结果,团队采用了 架构师带队、一线人员执行、团队集体验收 的合作模式。

架构师是负责人、责任人,协助梳理目标、分解里程碑、制定验收标准、定期检查。一线人员拿到的是一个可执行、能度量的任务,不需要太多思考就能准确实施。架构师定期组织一线员工检查中间状态,整体完成后团队成员一起检查结果、确保效果高质量达成。

关键点:推动被动老员工的个人提升有难度时,可以选择用合理的分工来充分利用人力。



Prev     Next