type
status
date
slug
summary
tags
category
icon
password
写在前面
近半年发生了很多事，平静的心境重起涟漪。口罩结束后，本以为经济开始好转，结果每况愈下，各种裁员降薪，不由得再次思考运维的价值。
本文所提及的运维指Linux相关的运维，不含网络运维、桌面运维
1.运维HC的由来
如果业务规模很小，通常研发leader/架构师兼任了运维，不会需要专职运维。等业务大到无法兼任的时候，需要招聘至少一个专职运维。由于预算的原因，我相信大部分情况下会只有一个HC，对候选人要求较高，又不会特别高，基本是中级或者偏高级的水准。
中大厂的运维肯定是组或者部门的级别了，理论上会细分岗位，特别是会出现运维开发的HC，因为这时候开源产品已经不能满足Devops需求，不如自己模仿实现一套CMDB平台，也可以说是运维leader向上管理的一个体现。
2.市场的一些矛盾点
学历：通常运维的学历不会太高，毕业即入职中大厂做效能开发的运维不算。学历不高还想高工资？
经验：小公司运维涉及的技术栈非常庞杂，注定不太会有机会深入。而且量变带来质变，量少的情况下，很多场景只需要服务搭起来即可运行。而中大厂的运维通常专职某一个方向，比如开发、监控、分布式存储，缺乏全局视角的经验。基建好的公司，封装后的运维平台会让你模糊混合云、底层设施形态等，你根本不知道基础设施某些细节怎么实现的。
年龄：这是最现实的问题，“需要一个10年经验但是年龄低于30的高级专家”，可能会有年轻的专家，但是市场又有多少呢？
3.运维核心竞争力是什么
技术重要么？至少在国内的环境下不是，能够快速实现业务的技术就是好的技术。
业务是第一要务，其他都是辅助。故无论如何，开发的工资上限就是高。运维作为辅助工种，真正的竞争力在哪呢？大部分情况下，运维属于成本，成本就少不了节省。
一个悖论：生产环境不稳定，运维有啥用？生产环境稳定，要运维做啥？
自动化程度低的运维找不到工作，或者工资低。
自动化程度高的运维可能相对好一点，可一旦平台成熟了，你的价值还重要么？完全存在这样的情况：“既然点一下就能CICD，为什么要花钱在工作不饱和的运维身上，谁都能干的活。”
而且效能需求又不像业务需求那么必要，预算紧张的情况下，效率低一点无非是用加班抵消，反正压榨就是动动嘴。
4.自我评判
怎么确定自己的能力？如果工作中存在大量人肉操作，一天到晚累成狗，想一想根源是啥。
4.1.甩锅
不是运维的锅不要接，如何判断故障是代码问题还是非代码问题，非代码问题理论上都需要运维负责。
4.2.自动化
理想状态下，研发只需要管业务代码，其他都不用操心，实现这个需求需要运维做好自动化。如果不把人肉工作自动化，苦的是自己。
4.3.稳定性
出问题不可怕，能不能快速定位故障？不是自己的锅要甩出去。
5.最后
写了半天，愈发觉得没啥价值。苟住，等行情回暖吧。不要期待挪坑会好一点，哪里不是坑呢？看的视角不同，坑的深度不一致。