上周五马驰和来炜关于“运维岗位真的不能干了么？”的话题，老师们给了终结：
❝现在这个阶段，平台体系还没有那么完备，使用自助Platform+COE+BP（Business Partner）的架构来搭建运维体系看起来是靠谱可落地的。未来Platform足够好的的时候，可以缩减BP人力（BP也慢慢具备了COE的能力），Platform继续完备，可以继续缩减COE，再之后，嗯，运维和研发可能就都不需要了吧。
❞
其中有几个概念我们需要搞清楚：
自助Platform，由企业不同团队根据自身业务需求搭建的功能性平台； COE领域专家，不同的平台团队需要相应的领域专家来进行指导，来应用最佳实践； BP业务伙伴，专业的外部供应商，通常提供更专业的SaaS服务，为平台或公司赋能；
没想到”自助Platform+COE+BP（Business Partner）“这个看似简洁的结论却一下子将我敲醒，此时“运维岗位真的不能干了”才下眉头，而”如何成为COE领域专家“的想法却上心头。为什么会有这个想法呢？可以将”自助Platform+COE+BP（Business Partner）“的理念结合企业监控平台建设来分析下。
自助Platform
相信有点技术的企业一般都会选择自建监控平台，可使用的主流开源方案有：
Zabbix Prometheus ELKStack Open-Falcon 夜莺 Grafana 等等
通过以上工具的结合使用，基本上可以实现多维度+图形化的监控，如：
硬件级别监控 操作系统级监控 中间件级监控 数据库级监控 链路追踪级监控 容器级监控 日志级监控 业务流程级监控 安全级监控 等等
但是由于存在多种监控工具，产生数据孤岛的情况就无法避免，这是自助Platform的一个痛点。除非团队中有一个COE领域专家，能够知道开源方案的痛点，并带领大家跨越这个鸿沟，向指标、日志和分布式追踪的可观测性建设迈进，更好的为系统容量评估提供数据分析。
COE领域专家
多维度的监控覆盖的范围比较广，涉及的领域及相关岗位有：
基础运维：IDC基础设施，物理机、网络设备、安全设备、存储设备等； 应用运维：应用系统，SpringCloud、健康检查、ELKStack、Skywalking等； 中间件运维：中间件，ZK、Redis、Kafka、Rabbitmq、Rocketmq等； 数据库运维：关系/非关系型/时序型数据库，Oracle、MySQL、MongoDB、InfluxDB等； 容器运维：云原生系统，Pod、Deployment、PV/PVC、SVC等； 业务运维：各业务条线流程； 安全运维：站点流量、渗透、高防CDN、全流量等；
综上，多维度监控的覆盖范围和精确度离不开各个COE领域专家的指导与交流。但人的精力是有限的，团队要想做好各自领域的监控，也是要付出一定的努力的。
SaaS
相较于BP（Business Partner），我更希望将此部分为SaaS，毕竟外部厂商提供的专业化的服务才是我们处理痛点的解药。虽然我们通过自助Platform+COE领域专家，在一定程度上解决了业务连续性问题，保障了业务系统的SLA。但是我们仍不可避免的会遇到以下的某个问题：
监控平台的多数据源形成的数据孤岛； 网络抖动、集群异常产生的多数据源告警泛滥； 缺少对历史告警数据的根因分析，以形成更好的故障自愈方案； 通过告警如何更精准的定位故障，进一步减少MTTR时间；
当我们无法做到十全十美，但是我们可以借助外部厂商的能力来帮助我们将平台建设的尽善尽美。专业化的SaaS服务能给我们更好的赋能，让双方的都能实现最终的双赢。
运维的发力点
经过以上对监控平台建设过程的分析，我们可能会对”自助Platform+COE+BP（Business Partner）“的思想有了进一步的理解，那么运维的发力点在哪？
如果你初入职场，你可以通过监控平台的建设来构建自己的知识体系； 如果你是职场中生代，你可以结合监控来深耕某个或多个领域，毕竟监控面向的就是各个维度的痛点； 如果你是职场老鸟，你可以结合监控去建立一套自动化运维体系，以便和监控对接更好的实现故障资源，这也意味你们的自动化能力将达到L3-高级（全自动化），是一种自我价值的体现；
当走过监控平台建设之路后，回首望去，作为运维我们可能已经具备了”知识体系+解决方案+自我价值“的COE领域专家的能力，这不仅是一份自信，更是一份能让你从被淘汰大军中的分母走向不可替代的分子中的真实实力。