3

终结这个话题：运维岗位真的不能干了么？

 1 year ago
source link: https://www.51cto.com/article/751144.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

终结这个话题：运维岗位真的不能干了么？

作者：SRETalk 2023-04-04 14:26:25
听两位老兵分享了一些他们各自的观点，受益匪浅。今天抓紧记录一下，以免忘记，算是对直播的一个复盘。
73d9b3b384028adbb437635d2d5d456101d965.jpg

上周五马驰和来炜在线交流，话题是运维岗位真的不能干了么？我作为主持人，既是点火的又是拉架的 :) 听两位老兵分享了一些他们各自的观点，受益匪浅。今天抓紧记录一下，以免忘记，算是对直播的一个复盘。

关于工具平台

工具平台会取代一部分人工，这个其实是显而易见的，无需多言。

但是工具平台谁来构建呢？这个值得捋一下。监控系统、CI/CD的平台、混沌工程的平台、中间件服务等，都是Platform，由Platform Engineer来构建，简称PE。PE显然是拆成很多小组的，每个PE小组负责有限的几个平台。这些零散的PE小组整体可以组成一个大的团队，比如叫基础架构团队，也可以拆到多个团队，比如跟工程效能相关的PE小组放到一个部门（比如效能工程部门），数据库、大数据相关的PE小组放到一个部门（比如数据部门），稳定性保障相关的PE小组放到一个部门（比如运维部）。

这个组织的划分，不同公司可能不同，关系倒不是很大，关键是PE团队应该怎么开展工作？PE团队核心要做好以下事项：

  • 构建好用的平台，让业务研发团队来自助服务
  • 平台要沉淀最佳实践。平台需要满足业务，但也要有业界最佳实践，理论上，如果业务需求和业界最佳实践相冲突的时候，尽量应以业界最佳实践为准，如果短期实在无法做到，也应该制定分步落地的计划，争取未来要做到，否则个性的东西、反模式的东西越来越多，Platform侧就会越来越难受，最后不堪重负，推倒重来，一地鸡毛
  • 要想方设法使用平台来落地规范，而不是用规章制度来落地规范，马驰举了一个例子挺好的，他们有个规范，是要求业务程序不能利用本地磁盘存储状态数据，他们没有把这个作为红线法令颁布，而是明确告诉业务方会定期重启容器，让容器漂移！其实用过aws的人应该知道，aws的虚机有的时候也会莫名重启，面向不可靠的基础设施提供高可用的应用程序，本就是应用研发人员的职责
  • 需要COE（领域专家）来指导Platform的演进，因为擅长数据库的架构师未必擅长Hadoop，擅长Hadoop的架构师未必擅长可观测性系统，擅长可观测性系统的架构师未必擅长混沌工程。

但所有的Platform都不是一蹴而就的，如果还没有这些Platform，怎么办？公司应该先去招聘COE，让COE来一边做业务顾问，一边建设Platform的能力，业务发展很快，Platform自研太慢，也可以寻求外部供应商的解决方案。甚至COE本身，都是可以寻求外部解决方案的，视情况而定。

关于外部供应商

大家直观上会觉得：欧美的公司更乐于采购SaaS服务，国内的公司更乐于基于开源自建。是不是因为国内的公司理念不行？不尽然。国内很多领域缺少靠谱的ToB企业和产品才是最核心的问题。试想，如果某个ToB公司可以为甲方提供：

  • 优秀的、先进的方法论
  • 稳定的、易用的产品
  • 优秀的、稳定的客户成功团队，帮助客户更好的落地最佳实践
  • 价格上，比甲方自己招聘人员自研更便宜

只要CXO脑子没坏，肯定会选择引入这样的外部供应商。但是这样的ToB公司有么？这是个大大的问号。我们创建快猫星云公司，为客户提供可观测性产品，力争成为这样的供应商。希望业界ToB同仁一起努力！

延展一下择业问题，虽然某个细分领域可能现在还没有很好的供应商，但是3年以后呢？5年以后呢？国外是不是已经率先有了？国内是不是有潜力不错的供应商了？如果已经有了，兄弟，你还敢继续投身在这个细分领域么？是否应该早做一些打算？

当然了，对于未来的预估，我们通常过于乐观，也过于悲观，对时间的预估，通常预估的超前，也预估的滞后。道理如此，兄弟，就看你怎么判断了。

关于应急故障处理

应该由研发来OnCall故障响应？还是运维？这个问题很有意思。马驰认为，线上80%的故障跟变更相关，变更是研发做的，研发显然更熟悉，让研发来OnCall故障响应，就意味着，80%的问题研发可以更快的响应。

业务研发如此，数据库变更、基础网络变更、接入层的变更，都是同样的道理，做变更的那个人来响应自己的服务的故障告警，看起来是比较合理的。

实际上，这取决于两个前提：

  1. 监控、可观测性做的足够好，变更导致的问题能够通过这套平台及时发现，大家加油，希望每个公司都有一套完备的可观测性体系
  2. 变更引入的问题是即时体现的，有些变更引入的问题如果一周之后才出现，做变更的人也很难怀疑到自己头上

其实我们可以分两种情况对待，变更之后的服务稳定性监测，本就是这个做变更的人的分内之事，日常OnCall是另一个场景，单独对待。那日常OnCall应该由谁来做呢？应该是那些可以直接参与故障定位、止损的人，道理很明显，如果OnCall的人收到告警还需要去联系别人，那这个故障止损的时效性就太差了。

所以首先，应该对告警分门别类的处理，不同的人OnCall不同的告警。所有的告警都交给研发或者都交给运维，这种绝对的做法是不合理的。

关于变更发布

最终目标是有共识的，就是让业务研发可以自由发布版本，但是我们又希望受控，希望安全的发布，希望在发布的同时保障业务连续性。这就对CI/CD的系统提出了极高的要求。

如果不管不顾，变更系统的底层就是去一批机器上批量跑个脚本的事情。但是附加了上述这些要求之后，就困难了很多，变成了一个系统性工程。

业务研发侧，需要做好埋点可观测，需要监控类的系统能够及时发现问题，甚至告警之后自动阻断发布流程。需要有一些蓝绿发布、金丝雀发布的手段落地，需要有些自动代码扫描、安全扫描的能力，工具体系不完备，一味地要求研发确保变更可回滚，确保变更安全也是不合适的。CI/CD的能力水平如何，基本可以看出这个公司的技术实力。

如果你所在的公司，还是研发给运维提单，运维去线上操作，要掂量一下这么做是否合理了哈。当然，上面的做法更多的是偏互联网的做法，未必适合所有的公司，这个直播也只是提供一个思路，你要自行斟酌。

当然了，这个理想的情况怎么达到？在这个理想的情况达成之前应该怎么一步一步走过去？时间问题，直播里并未探讨。如果公司的业务适合跑在Kubernetes上，用Kubernetes来构建这么一套体系是相对容易的，可以尽快行动起来。如果公司的业务必须跑在物理机、虚拟机环境，那就先搞一个统一的变更发布平台，然后哪里缺失补哪里，逐渐完善了。

关于成本优化

两位嘉宾谈的不多，不过大家对这个事情都非常慎重。提醒大家：

  1. 人比硬件贵，千万不要做花费了5000万的人力，节省了4000万硬件成本的事情
  2. 要给业务留出足够的冗余算力，如果资源用的太过紧张，该批的预算不批，因为容量导致故障的话，客户体验受损、舆论不利，得不偿失
  3. 可笑的例子是，用3000万买量，为了节省300万的硬件成本，没抗住量，真的就呵呵了

现在这个阶段，平台体系还没有那么完备，使用自助Platform+COE+BP（Business Partner）的架构来搭建运维体系看起来是靠谱可落地的。未来Platform足够好的的时候，可以缩减BP人力（BP也慢慢具备了COE的能力），Platform继续完备，可以继续缩减COE，再之后，嗯，运维和研发可能就都不需要了吧。

责任编辑：庞桂玉 来源： 运维百家讲坛

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK