OP：运维工程师(Operations Engineer)
申明一下，这里对于 OP 运维的定义，可能跟传统的有所区别，是按照我们的组织特性和结构做的定制化定义。
定义： 其实运维工程师严格意义来讲，就是质量的护道者。除了 devops 环境、网络、服务器、服务的自动化构建发布，稳定、安全性保障之外，还应该对组织内部的管理协同平台进行监管，安全、保密、账号授权等，以及版本管理和日常运维工作。当然除了这些之外，还需要对承接到运维环节的输入输出标准化的控制和跟踪回归。
⚖️ 履职规范
一、职业化运维工作
1. 服务器整体架构规划
场景：👀
OP 在接手一个新项目或维护现有项目时，需要根据项目的实际业务需求进行服务器架构设计。这个场景通常发生在项目启动初期或需要对现有架构进行优化时。
通过实际业务进行服务器架构设计，一般会采用传统的多节点应用服务器配置，具体详细解释见输出备注。比如能详细描述服务器的数量、配置、网络拓扑、负载均衡策略等；包括服务器的安装、配置、测试、部署等步骤的详细文档；对设计方案进行风险评估，包括可能存在的问题、潜在的风险以及相应的应对措施；对设计方案进行性能和安全测试，确保满足项目的需求；为运维团队和其他相关人员提供培训材料，以确保他们能够理解并维护新的架构。
🦴 输入
根据能详细描述项目的业务需求、性能要求、安全需求等的需求文档，结合现有的资源，以及行业标准，若有甚至参考历史项目的架构设计和运行数据。
🎗️ 输出
01-服务器架构设计方案|02-部署文档|03-风险评估报告|04-性能和安全测试报告|05-培训材料
当然，这个场景触发的前提是，需要针对客户，以及自有产品，制定体系化的服务器整体架构规划的场景，其他可以针对裁剪。
2. 网络环境
场景：👀
OP 在规划项目的网络环境时，需要确定部署的应用服务是否需要进行外网访问，以及项目部署的环境中是否存在 VPN、防火墙等网络防御模块。
这个场景主要是负责确保项目的网络环境能满足业务需求，同时保障网络的安全性。所以除了需要了解项目中各个应用服务的访问需求，还要了解项目的安全要求，包括是否需要 VPN、防火墙等网络防御模块，以及这些模块的具体配置要求，了解现有的网络环境，包括网络拓扑结构、网络设备配置、网络带宽等信息等等。
🦴 输入
根据业务的需求，安全要求，现有的网络环境情况等等。输出可以详细描述项目的网络环境规划，包括应用服务的访问权限、网络防御模块的配置等；根据网络环境规划方案，生成网络配置文件，包括路由器、交换机、防火墙等设备的配置；制定项目的网络安全策略，包括访问控制、入侵检测、数据加密等措施，以确保网络环境的安全性；对网络环境进行测试，确保网络环境的稳定性和安全性，同时记录测试过程和结果，形成测试报告等。
🎗️ 输出
06-网络环境规划方案|07-网络配置文件|08-网络安全策略|09-网络测试报告
3. 项目环境部署
场景：👀
OP 负责将应用系统部署到生产环境中。此次项目采用特定的系统和编排模式，需要按照相应技术要求和流程完成整个部署工作。
比如应用系统采用 Centos7.4 系统，基于 docker-compose 编排的模式进行项目部署。通过 docker-compose 编排成功启动并运行，且各组件之间能够正常通信和协同工作；并且记录整个部署过程，包括执行的命令、遇到的问题及解决方法、各组件的最终配置参数等，方便后续维护和问题排查；同时对部署后的应用系统进行初步检查和测试，生成运行状态报告，说明系统是否正常运行、各项性能指标是否符合预期等。
🦴 输入
根据应用系统代码及相关文件，准备好的 Centos7.4 系统环境，包括系统的基本配置、软件包安装等，还有 docker-compose 相关知识和工具准备，以及项目部署文档和需求说明作为输出的重要依据。
🎗️ 输出
10-成功部署的应用系统|11-部署记录文档|12-运行状态报告
4. 腾讯工蜂 Git 代码配置
场景：👀
在这里，需要 OP 赋能开发伙伴，让开发伙伴可以根据分支推送触发的方式自动的去构建发布代码；
需要运维伙伴在代码管理平台做相关配置，比如代码推送 ssh 链接配置、Dockerfile 构建脚本的配置，jenkins 脚本的配置等。
🦴 输入
在工蜂代码托管平台，根据源代码，配置文件脚本等。
🎗️ 输出
13-Dockerfile配置文件|14-前后端jenkins配置文件|15-nginx配置文件
5. 项目部署
场景：👀
在项目即将进入部署阶段时，OP 需要负责确定和准备部署环境。这一步骤至关重要，因为它直接关系到项目能否顺利运行及其后续的性能表现。
OP 在这个环节，需确保所选环境符合项目的技术和性能要求。比如环境准备，代码编译和构建，配置数据库，文件资源及应用程序部署等。
🦴 输入
这里一方面根据项目的需求文档（功能、性能、安全等），或技术选型文档（如技术栈、框架、数据库等），以及硬件资源清单作为参考依据（服务器、存储设备、网络设备，规格和数量等）。
🎗️ 输出
16-部署环境信息表
这个输出跟项目的那个《各环境及服务器资源信息表》保持一致即可，只不过一个分一个总。列项应更加详细一些，有环境，硬盘设备配置，操作系统，网络拓补，配置等，ip 地址分配、路由策略、防火墙规则等，最后所属分配的项目。
6. 日志管理
场景：👀
在构建高效且可扩展的日志管理诉求下，需要合理的日志架构。才能满足涉及到日志的生成、收集、存储、分析和展示等多个环节的要求。
那么针对于不同场景下的日志管理诉求，都要围绕它的架构，需要 Elasticsearch 部署、Kibana 部署、Logstash 部署、后端项目代码修改等动作来达成这个目的。
🦴 输入
这块儿会根据系统架构图，确定日志生成源和收集点，明确日志的种类、格式、存储周期和分析需求等；还有准备 Elasticsearch 安装包、服务器资源清单的信息，Kibana 安装包、Elasticsearch 地址、Logstash 安装包和日志收集配置，包括后端项目代码库和后端的日志格式要求，Logstash 索引名称跟 Kibana 配置文件等等。
🎗️ 输出
17-日志分析报告|18-日志管理文档|19-日志归档和销毁记录
旭杰整的这些太专业了，超出我的专业解读范畴了哈哈，最终解释权由旭杰。。以上所有职业化运维动作，具体的输出根据实际情况动态裁剪。
7. 监控管理
场景：👀
在运维工作中，需要对软件系统的运行状态进行实时监控，确保软件能够稳定运行并提供服务，并且能提供异常预警和通知。
那么就需要通过比如安装 Zabbix 及配置相关工具包，创建数据库授权、导入初始架构和数据等，通过 zabbix 监控平台配置相关的一些告警设置来实现有效的监控管理。
🦴 输入
根据如 zabbix 监控系统的配置信息，像性能、异常、告警等方面，数据阈值等维度。
🎗️ 输出
20-zabbix相关配置操作说明|21-告警机器人推送
二、定制化运维工作
根据 天智 AGILE TEAM 组织结构的调整优化，业务场景及工作需要，对于运维的设定增加了定制化的其他内容，计划未来做整体的融合，所以定制化的运维工作在 OP 职业化输入输出的基础上，进行除保障性运维之外，追加定制化经营指标层面，精益赋能的运维工作。
1. 协同平台监管
场景：👀
对于研发部门，针对于项目协同上下游的协同工具平台，进行统一监管，一方面保障规范，一方面保障安全。比如员工入离职，账号授权，各协同角色的平台使用是否规范等等；
其实针对上面的场景，导致各协同平台的使用和管理比较混乱，项目管理的禅道、文档管理的语雀、代码管理的工蜂、接口管理的 apifox、原型设计管理的蓝湖等，乱七八糟不规范的管理和使用，其实隐性的给大家带来很多心智负担和沟通成本、时间成本，导致后续的使用和维护性变得极差。
🦴 输入
这里运维倒逼，督查各角色明确使用规范，以此作为检查点。比如产品组出具蓝湖使用规范、前后端出具 apifox 使用规范、工蜂使用规范、TEC 小组出具并对语雀使用规范，PMO 小组出具禅道使用规范，一并提交运维统一管控，由运维出具协同平台管理规范，涉及创建和销毁账号，角色授权等等；其实后续的运维平滑承接，前瞻的布局和动作就应该从此刻开始了。
🎗️ 输出
01-蓝湖使用规范|02-apifox使用规范|03-工蜂使用规范|04-语雀使用规范|05-禅道使用规范|06-协同平台管理规范
2. 项目标准化输入输出检查
场景：👀
未来运维伙伴要承接项目的运维工作，更多的可能是对于跟甲方签订商务合同方面的 1-2 年的质保运维，那么对于乱七八糟不成体系的项目产出去做运维，业务、技术、文档各方面断裂不规范，不了然，没把握，除了当传声筒，谈何运维；
所以，我们的运维伙伴，如果对项目过程中的一系列文档，产出，没有一个清晰的认知和解读甚至把控，我觉得就是灾难，运维就是个没有体面边角料工，我不想让大家如此定义我的运维伙伴。为了避免这种问题，那运维就要职业化的，严肃的规避运维风险，提高对运维工作承接的要求，最起码应该有的输入输出没有，达不到运维的要求，打驳回去，并应该在这个过程中，提前准备，走查，梳理项目运维承接问题清单，少一项划一项，从而推动和规范研发测到运维侧的工作交割流程。
🦴 输入
完全根据项目的产出物，结合专业标准在项目中的输出要求，广度和深度系统的把控，作为平滑承接和输出的输入条件。
🎗️ 输出
07-运维项目承接问题清单
3. 运维跟踪
场景：👀
当项目上线以后，运维伙伴要格外关注，上线后肯定会有客户密集也频繁的反馈，这个时候在验收之前，都是由原项目开发人员处理问题，运维伙伴要跟踪关注，了解情况，积累经验。
运维跟踪，跟踪上线情况，为后续的验收后运维承接做准备，规避不能平滑承接风险，一方面来自研发侧，一方面来自客户测，关注项目开发，测试人员跟踪处理情况，典型事件和问题进行记录组织讨论。
🦴 输入
这个时候更多来源于上线后的客户反馈，这个阶段若识别对后续的运维承接不产生风险，不强制要求有输出，否则你应该输出典型事件记录表。如测试严重不过关，产品测需求把控不到位，项目侧客户风险等等。
🎗️ 输出
08-典型事件记录表
4. 运维执行
场景：👀
当以上的工作都按照要求达成了，运维顺利承接了后续的工作，就需要自验收报告签订日起，担负起后续的常态化运维工作，一方面给开发团队减负，一方面也能培养运维意识的开发人员。
这样的机制如果健康的执行下去，给团队带来的赋能和收益是不可估量的，运维的保障职能才更加立体，赋予运维团队的将是责任，激励，也能使团队更加凝聚，使协作更加的健壮，不然，哪个环节掉链子，哪个环节就进入运维侧来补台和拉扯。
🦴 输入
在这个运维执行的过程中，有意识的按要求去构建和完善，运维标准化流程，同时通过工单、各种反馈形式，构建问题库，如（增补需求/变更需求/质量问题/其他问题等等）。问题库也是一种解决经验的宝贵积累。
🎗️ 输出
09-项目运维问题库
5. 运维工作协同
场景：👀
在运维期间，应该有意识的去进行运维分级，比如 1 级解决不了的走专业组，2 级，3 级走运维自己内部，3 级非功能性的的辅助工作累计的同类问题较普遍，可以请产品协助培训，运维学习等等）。管理层面在比如遇到一些复杂的问题，团队中的运维执行伙伴无法处理的问题，根据统筹，对接到项目经理、产品组、专业组、安排具体的运维人员对接解决。
这个场景比较特殊，需要我们的运维负责人进行有效甄别，以及对运维伙伴人员能力的判定，按照协同配合流程，具体到人，截至时间解决问题和规避该类问题。这一块也跟后续关于运维负责人的一些要求息息相关，迥异于其他专业组，本年不做 Leader 的指标要求，但需做指标准备。
🦴 输入
这一块没什么好说的，完全根据运维服务质保内容，提供和尽量保障 0 投诉，0 事故。
🎗️ 输出
10-运维工作安排记录表
✨ 运维 Leader
运维负责人的核心要求，除了职业化的刚需保障之外，更多的是针对定制化的内容，通过一系列的动作，能项目成本、团队精益赋能，所以对于定制化这一块的核心诉求就是统筹，安排，衔接，监管，保障这几个关键词。在做好这些的基础上，再同样去根据运维计划安排，动态调配资源，发挥人员能效，同时还要围绕部门整体要求下的，项目建设、专业提升及分享沉淀，以及标准化要求，培训管理等内建工作。
要求及期许：
由组长拟定小组管理体系和考核标准，明确小组的职责和目标，上报部门确认，最终完成小组管理标准化体系化落地，评审定版，版本管理，上传语雀，上报公司归档批复，部门对小组预期要求，应包括但不限于如下内容；
1. 管理思想
场景：👀
管理是一种行为和动作，执行的目的和过程，应该都有相应的理论作为指导和参考依据。认知，执行，验证缺一不可，我们的管理人员，需要做好角色转变，首先要提升和改变自己的认知，然后要去理顺章程，理顺了，再去说，人、事、物如何去有效调配管理，管理不能仅浮于表面，也不是某一个点的问题，而是基于面的，网状的，立体而发散的，要尽量的让自己知其然，知其所以然，用好的，优秀东西，同化和影响，引导，做这些之前，你可能需要深入了解被管理的人员，他们的能力，擅长的领域，工作的安排，专业的输入输出，优点以及缺点，甚至是他们的诉求和成长以及发展和价值。
那么作为组长，你要做人才识别，做一下小组的人盘盘点，你要有盘点的思路和章程，你对专业小组管理的理解，对同属性伙伴专业输出的识别，有一套方法论，基于这个方法论，针对动态的业务场景和公司战略需要，有人才分类匹配的依据，并且针对态度能力的融合，可以针对性的输出管理办法和考核标准，让大家知道需要把做的事儿，如何职业化的去做到什么程度，并把它的价值和能效体现起来，激活人才，凝聚一体，如臂指使。
🦴 输入
公司及部门对于专业组管理要求，年底公司各组织人员的人才盘点动作，但希望各负责人把这一块做的超出预期，莫要流于形式的交作业，而是真的在其位谋其政，有一些自己的思考，沉淀，总结和章程在里面。
🎗️ 输出
01-人才盘点章程|02-人才模型（方法）|03-人才分类（依据）|04-小组管理办法|05-考核标准
尔后由 TEC 小组参与评审后定稿公司级终审。
2. 管理动作
场景：👀
小组管理应该做哪些事情呢？应该有哪些事件源和动作协同呢？如何穿针引线的去引导和合力呢？对管理动作的执行，有哪些动机和预判呢？对于认知和能力，如何扁平化达成共识呢？我们的管理者，不妨好好思考一下，它应包含但不限于以下内容。
那么简单直白一点说，一线的管理动作是需要一些行为执行来拉通分工协同的，动作就是其中一个最直观的抓手；比如小组内部分享，识别擅长和偏好，优缺点，引导性和针对性的使成员共同成长；小组双周会，调动小组的集体力量和智慧解决点点滴聚焦的问题，以面破点，落地解决问题，体现赋能，也为后续的工作计划和人员调配有一个前置清晰的依据。
🦴 输入
可能是项目的刚需，可能是标准化体系的内建，可能是能力成长的需要，也可能是工作的把控、成员的援助诉求、业务支撑点的洞察、离散性的产品问题等等，不一而足；
🎗️ 输出
06-小组分享培训计划|07-小组双周会及成员问题跟进表
分享培训频次（至少月度 2 次），主题方向（项目疑难杂症，工作流，技术方案等等），分享资料归档并上传语雀，成员分享培训评价管理，汇总归档；
小组双周会，成员两周工作情况互通，遇到的问题，需要协助解决的事项，输出待解决事项清单（提出人，内容类别，内容详情，解决时间，解决人），上传归档及跟进解决，双周会不要求会议纪要，但是要有 成员问题跟进表。
3. 管理人员
场景：👀
部门计划将人员调配的权限，逐步下放到专业组负责人手里，后面组织结构的响应公司战略部署部门做动态调整，拉通专业组和项目组的高效协同，使小组管理者对成员工作有直观的洞察（能力/态度），建立 T 型管理梯队。
要做到人员的有效调动，第一，对成员能力和项目匹配度有认知和判定；第二，能识别项目计划制定专业计划，避免人员空闲稀释成本和能效；第三，把控项目上专业人员的风险，有补台补位及预防措施，并确定末尾红线替换淘汰机制（比如任务完成度和输出要做到什么程度）若因为组人员调配，影响到项目组工作计划造成时间冲突的，需跟项目负责人和项目计划达成一致（计划识别和同步），有分歧上报部门调整优先级（尽量避免）。
🦴 输入
人员的调动依据一定是项目计划和调动事件源，根据运维计划调动的人员安排，需上报部门记录和确认，同时，要去识别人员空闲率。避免忙的忙死，闲的闲死，后续根据职级跟指标相挂钩。
🎗️ 输出
08-运维人员配置表|09-资源日历表
4. 培养和晋升
场景：👀
每个人的认知，能力，经历，沟通力，理解力，学习力都不一样，我们的管理者，如何把这些基于点的优点，树立榜样，作为标品和基线，提升和补缺典型的缺点，并且在这个过程中，为组织产出和留存，可识别的，直观的，有价值的沉淀，思考，和创新。比如一个产品，方案编写和演讲的能力，就是一个典型，如何去培养典型的能力。
回归职场，职业发展的路径，公司团队发展的需要，内建都是核心，练武不练功，到头一场空，培养和晋升是相辅相成的，通俗直白一点说，你要晋升，就培养出来一个人来可以替代你现有，要把价值显性化，实例化，具象化，这才是管理的价值，赋能使能。
小组成员能力培养，要定指标，定要求，有培养计划和课题，结果可验证，如业务域，演讲能力，方案能力，需求管理能力等等，用输出沉淀和结果说话（也会作为晋升依据）；专业管理人员，需跟成员明确梯队匹配分级，未来我们配合人力资源把人员职级细化，明确晋升路径。
Core
TIP
对于一个合格且优秀的组长，一定要是制度流程的坚定拥护者和执行者，上传下达，上行下效，尽力尽心尽责的做好职能管理，树立好的标杆典型，杜绝劣币淘汰良币的情况发生，所以在这个过程中，就要做好检查，有效监督，积极纠偏，努力去做提升。把事、人、情分开来看。我们的组长，不但要对项目的输入输出有哪些洞若观火，还应该对输入输出到什么程度了如指掌，再好的制度、流程、规范，没有检查监督，纠偏和优化，最后就会不了了之流于形式。管理角色需要提升自己的认知，打败自己心理的矫情和软弱，规避本位主义的趋利避害，才是迈向管理角色坚实的一步，应该用更健康的心态去看待和开展管理工作，最终的目的，都是为了精益赋能，降低沟通和试错成本，而不是为管理而管理。