前言
420有幸做了人生第一次的运维培训，如果给自己打一个分的话100分估计只能给个60分。趁着热乎劲还在总结一下。
做的好的地方
从业以来碰到的各种问题和经验都能经过思考输出，在讲课的时候即便没有讲稿也可以持续的输出。
互动做的还不错，可以有效的进行一些提问和让线下的同学产生一些“矛盾”和讨论。
不紧张，在40来个老运维面前，能够给做到不怯场沟通。
前期准备了一些补充材料，弥补了课件内容的方向单一的问题。
做的不好的地方
没有前期充分调研客户的部门分布和领导期望，挑起了中心和地方部门之间关于告警之间的激烈讨论。
材料依旧需要精进，尽管之前把一本经典的运维书籍读了好多遍，但依旧感觉内容还有提高的地方。
应该加强一些课程上的比赛和激励机制，这次忽略了激励机制，虽然内容比较好，但他们自己之间的互动可能更好。
加强体力锻炼，本次两天的课程，其中第一天他们有一些自己部门的分享，也参加了下。基本上第一天接近于12小时，第二天也超过了8小时的课程。所以体力消耗上还是非常大的。
做完培训上的分析，接下来可以说说本次案例企业遇到的一些问题和解决之道。
背景/问题
企业分为中心运维和区域运维两个部分，刚刚实行了双向汇报的机制。平时坐到一起沟通的机会甚少。
区域运维的水平不一。有的人员充足，有的只有一个单点的运维。有的责任心较强，可以主动的处理故障和处理告警。但有的只能处于被动接受告警的情况，且对于系统的架构并不了解。
中心运维强管理，虽然嘴上说着有商有量。但还是做的ITIL那种管控的文化。修改一个监控的阈值都要进行讨论审批，理由是怕下面的运维瞎改。而且阈值是经过中心专家评审过的，应该不会有太大的问题。应急响应是要求区域运维3分钟响应告警，30分钟处理完毕。
以上是这种架构组织经常遇到的情况，其实只是大家屁股坐的不一样并且看待一个相同的事件的时候，有这不一样的文化的问题。倒是有点类似于《置身事内》那本书里写的中央与地方的关系一样。
如何破解
破解之道估计长期只能依靠时间上的组织文化变更，短期只能依靠哪个部门更加得宠和嗓门大。这需要一个过程，但是在过程的期间，可能出现各种阵痛。比如部门间的不和谐、人员流失、相关经验得不到传承、故障频出等等问题。
好在这个部门的运维负责人不是空降，而是从本企业一线提拔上来的老运维。对于运维的责任心以及各种细节都比较了解。但也对于山高皇帝远的区域运维的管控力上力不从心。只能从加强一些中心运维的能力和管控方面着手。并且HR部门对于运维方面的培训和团队建设也比较重视，毕竟运维出现过很多次问题和故障直接影响了公司的收入。以前这个运维团队是放到了研发团队里，出现了几次故障，公司越发的感觉运维的重要性，把运维团队独立了出来。
如果一个企业的业务和运维强相关，例如运营商、电力这种广义的运维没有，基本上就相当于不存在本行业一样。这样的运维可能更幸福一些，但也偏保守一些。而金融、地产、物流等这种没了互联网可能也照样活（有些行业没了互联网现在可能也不太行，但互联网对于他们应该是锦上添花的事情）的行业。可能互联网+的情况是需要一个创新和速度。因为失败了成本也比较低，不如搏一把。
这个被培训的企业就是在一个偏传统的运维模式，但是用的技术却比较新。且受制于甲方爸爸的硬件和资金的需求。自己只作为运维方。所以中心运维强管理的模式还是比较适合，只是可能前期用力过猛，地方有反弹罢了。但可能也存在一定的风险就是前期的一些阵痛和后期可能又被各地诸侯直接打回原形的问题。
培训时遇到的一些问题
没记住每一个问题，但大多是关注在如何“甩锅”的问题，因为变更的时候让他们背锅的地方和边界有点模糊不清。加上研发和甲方爸爸的双重压力，以及中心运维的强管制。这些问题其实都可以用前期规范变更操作进行规避。
还有一些问题是关于变更的技术问题，比如如何灰度、监控如何处理毛刺等问题。这些其实都有一定的最佳实践，想比技术来说，已经算比较好解决的了。
最后一种问题其实还是集中在中心和地方的矛盾上，地方说人少没办法符合中心的要求，中心说地方没有好的责任心和主动意识。这种问题还是建议他们进行轮岗，增强一种同理心。然而，在这种矛盾已经快到了激化的情况下，不知道他们能不能听得进去。
就像《高效能团队模式》里说的平台团队一样，对于平台团队的定义应该是：
平台团队的目标是使流动式团队能够以高度自治的方式交付工作。流动式团队在生产环境中拥有构建、运维、修复应用的所有权限。平台团队提供的内部服务使得流动式团队无须开发底层服务，降低了认知负荷。
而目前大多数的实际是：平台管理团队。除了用我的平台，还要管理你的行为。例如：调整监控阈值要经过管理团队的审批。平台使用的问题要去阅读厚厚的说明手册。
关于中心化的监控
这个问题也很有趣，在介绍关于监控的监控的问题上，引出了是否要有一个中心化的监控去监控各个区域的监控系统的问题。因为是中心和区域的关系，区域目前有一个自己的监控系统，把一些告警信息发送到中心统一的告警平台中。来实现告警的追踪。下一步打算把各个区域的监控数据集中收集展示。但却没有想好为何一份数据要存储两遍以及如何使用的问题。
其实这个问题最重要的就是ROI，监控数据存了两份其实并不是重点。例如如下的一些考量点则是存在这个中心化监控的主要问题：
- 统一展示：这个使用一个grafana就可以完美的低成本解决。
- 监控的监控：这个如果中心监控出现问题，也会让监控的监控出现单点问题。
- 数据集中：大量的无效数据在中心进行处理和告警灵活性和成本都不是一个最佳解决。
- 集中告警：告警目前各个区域的监控系统直接推送给各个区域本身的运维人员，集中了再告警反而增加了路径和故障点。
以上的可能不太是一个集中监控存在的意义，但一下可能对于集中监控存在的意义有了一些不同的理由：
- 统一的数据的分析：这个集中的意义就是一个数据湖的概念，过于分散数据可能不便于分析。
- 需要一些业务统计上的数据：不收集全量的监控数据，而是收集一些全局视角的数据，且不用于告警。可能是比较收敛的一个方式，兼顾了成本和管理的平衡。
总结
通过这次真正意义上的首秀，坚定了之后的一个大致的方向。以前的各种经验和一些好的书籍整理成自己的知识库。可以的话形成相关的书籍。不管有没有用，都是对自己这么多年来从业的一个交代。