运维 -> 架构师
我们不需要单纯意义上的OP，加监控、收报警、执行预案（重启/扩容），黑盒运维，做一些边角料的事情。
回想刚加入前厂运维部的时候，感觉运维各种高大上，各种骄傲。我们每天流量好几亿，我们拥有线上机器的work & root权限，我们各种部署，我们各种监控，我们各种容量规划，各种切流量保障服务99.999。
的确，你NB，了不起。
但这只是一厢情愿的骄傲，是属于个别部门个别牛人的骄傲资本。
当一个新人RD开发出各种ugly的代码，只为实现功能，性能、可扩展性通通不考虑也不会考虑的时候，需要你作为OP去擦屁股，加监控、收报警、服务出问题后case study问你为什么没提前发现，为什么预案执行的时间这么长? 你有什么好骄傲的?
当你上了N个模块但是不知道业务上都做了哪些升级，其实RD写的代码就是一坨屎，上了之后回滚，回滚之后又上，反反复复折腾到12点的时候，不禁开始怀疑这个角色存在的意义，TMD做这些都是为了啥?
当我跳出来，同组的一个小同学迷茫地跟我说，他现在身上有20个产品线，要走的话移交都不知道该移交给谁，但是一个人扛这么多实在是抗不过来。我跟他说，你不要把自己想的太重要，如果要走的时候没OP能移交，移交给RD可不可以? work/root账号初始化给RD可不可以? 本来就是人家写的代码，你能加监控，RD不能加监控? 你能故障之后重启、扩容，RD就不能故障之后重启、扩容? 这真的是有技术壁垒吗? 这些工作是他们做不了还是他们不愿意做?
诚然，大公司角色细分的厉害，说是可以提高效率，让每个人都可以深入自己的方向。可能也对，但副作用是各个角色之间是割裂对立的。我只管开发，实现需求，代码质量那是你QA要保证的事情，要不招你来干嘛? 加监控处理报警本身就是你OP做的事情，不然你们做什么? 当这样的思想泛滥的时候，作为QA、OP这样的辅助性角色，地位是尴尬的，内心是不爽的。
前厂至今没有解决这个问题，自动化喊了这么些年，真正的OP小弟小妹还是苦逼呵呵，报警几千条、上线到凌晨。为什么? 私以为解决问题的根源不在于自动化，而在于从哪个层面开始做自动化。可能是我图样，聪明如老大们怎么能不知道? 但怎么改变? 积重难返。
但，对于你这个傻OP而言，还是有改变的途径的。
RD代码写的烂，出了稳定性问题，反倒需要OP“推动”RD修改，RD还很不情愿地说，我这边下次迭代需求都排满了，你先通过扩容/自动重启解决下吧。这时候，除了吐槽’这个RD真TMD不靠谱’外，想想为什么你不能改代码? 想想会什么你不会改，为什么你没能力把这个系统的架构从一开始就设计成很健壮、扩展性很强的? “我是OP啊！这些代码、架构上的事不该我去干！” 如果你有这个想法，其他啥也别想了，专心抱怨、吐槽、推动RD吧。
想想google,facebook，没有QA，SRE是RD中技术的牛人，怎么做到的? eat your dog food。但如果RD不想eat their dog food，作为OP你该怎么办? 如果山不过来，你该怎么办?
阅读(1050) | 评论(0) | 转发(0) |
