运维团队
2021年12月底的时候，向老板提出了从产研团队退出的事情，将工作交由另一个小伙伴负责。我个人计划是，好好搞搞云原生运维的事情。
但，事与愿违😂
感觉也没过几天，刚准备午休，突然被告知，老板在茶水间等我。我顺着茶水间的路，往前走着，心里却思考着其他的事情，什么事情呢？难道又要回去带团队？🙅那我指定不干。就这样走到了茶水间。
茶水间整体的气氛，给人的感觉是较为轻松的。
行吧，聊吧～不想了。就一屁股坐下了。十几分钟过去后，我又领了个艰巨的任务。
公司要成立个团队，把项目上的运维工程师，收过来，统一管理。但这个事情的背景，极其复杂...第一感觉就是，这还不如带产研...
目前的背景是
- 产线的运维管理都是各个产线自己负责的
- 交付的工程师，属于交付团队
- 售前的工程师，属于售前团队
- 售后的工程师，属于售后团队
把这些人都收回来，这动作也太大了, 之后用人和管理等诸多事情，跨团队合作...事情永远远比想象中复杂
经过了一个月的调研，一个月的思考。最终出了一个团队规划，并完善了相关的细节点
团队规划
先聚后散。
聚，是为了通过大家一起努力，把体系建立起来，大家有规范、有标准、有积累、有成长。 散，散是为了更好的将工程师能力，输出并赋能其他团队
目标
一线转二线，对内提供产线、售前、交付、售后支撑，同时对外提供服务支持，逐步形成以内部运维团队为基础，驱动公司运维相关的工作的高效运转与合理分配
专业化分工
通过产线、职责的专业划分，让运维人员可以在自己所负责的模块做的更深入，更专业，从而更好的完成岗位职责，产出专业的知识文档，赋能内部团队以及服务商。
具体职责详情：
由于人员有限，项目较多，单个人员会负责多个项目，形成主备关系，当主负责人不在岗位的时候，如调休、请假等，则另一人顶替工作。在日常工作中，产线负责人会进行培训和分享，尽可能的拉齐各成员间的专业水平
专业化的分工，提升了团队成员工作的专注力，降低琐事的消耗，起到一定的降噪作用，从而提升工作的质量和效率，但对协同办公的要求也相应的提高了，所以后续需尽可能多的自动化
流程化服务
目前SRE运维的工作范围有云原生设计与维护，开发、测试环境维护与协助，生产运维，售前支持，售后支持，服务商支持，各种事项，繁杂琐碎，内外部人均有可能提出运维相关的需求，为统一入口，在DSM新增SRE技术支持和基础组件与微服务申请服务目录，统一进行工作安排和人员调度，避免工作杂乱无章，效率低下
通过流程这个切入口，逐步将运维工作进行收口
组件申请
技术支持
规范化操作
目前公司运维群体分为内部研发产线运维工程师以及服务商工程师，运维规范化操作主要是用来约束这两部分运维人员的操作行为。
目前内部运维产线运维，主要是云原生环境的维护，设计的主要内容除了常规的操作系统外，还涉及Kubernetes平台、业务编排以及运维监控、日志等等，云原生平台已有一系列的规范和流程支持，以确保各种变更操作等规范化，标准化，有迹可循**（运维即代码）**。
针对服务商，除了规范手册外，另提供了高危命令的规避工具用来规避部分高危操作
自动化运维
公司产品整个研发架构是微服务架构，且涉及多语言(java golang python nodejs)，相关的服务配置越来越复杂，变动的波及面也越来越广，若没有规范化、自动化的服务支撑，则后续的工作越来越难展开，需要投入的人力越来越大，运维效率和质量就无法保证。
针对重复性、批量性的操作，运维需要开发自动化工具、平台或脚本，尽可能的做到自动执行、一键执行逐步实现运维自动化。
目前已有的自动化平台：
- 管理平台
- 通知平台
- 脚本库
- 运维即代码
共享知识库
运维工作中，会遇到各种问题，总结各种经验和知识，对知识进行管理和收口，能更好的赋能团队以及部门，提升工作效率和质量。
知识库主要分为内部和外部两大类，内部知识库主要存放团队相关的资料和手册，方便组员进行信息的查找与对齐，避免出现过多的偏差。外部知识库主要存放项目实施相关手册和文档等，便于服务商的对接
总结
整体的规划以及有效落地，可搭建一个较为完整的运维体系，保证环境的稳定，提升运维质量和效率，到达降本增效的目的