今天是离职交接的第一天。
在过去的几个星期里，我经历了5轮电话/视频面试和2轮现场面试，最终在昨天晚上完成了和组长的沟通，启动了工作交接。
为什么离职
现在的我供职于国内某互联网公司的重要业务部门，从事着业务运维的工作。和很多互联网的运维一样，我们的主要职责是配合产品和开发进行业务的上线，同时兼顾效率、成本、质量，保障平台的稳定运行。算是一种技术工作。然而和Google的SRE不同，国内以产品和用户为导向的环境决定了运维很难在产品初期就参与进来。往往产品或者策划已经完成了他们的构想，开发已经开始编写代码的时候，才会联系到运维，申报机器和CDN资源，准备进行接入。同时开发的代码质量也未必可控，经常造成新业务开发上线以后半夜需要拉运维进行故障定位处理。我离职的原因当然不会这么简单，那么运维到底需要关注什么呢？
质量
质量是老板们最看中的一项指标，一个产品的好与坏，稳定可用占了很大比例。在互联网历史上就发生过多次大规模故障最终产品不得不停运，公司关门的案例，质量的重要性不用多说。质量的指标也包含了方方面面，请求耗时、是否失败、是否丢失数据等等。由于富媒体的使用，我们也对CDN的质量极其敏感，和CDN团队/公司的配合等。我所在的团队已经比较好的用各种机制保障了质量，数据上报、监控、值班、报故障等，以及处理故障、问题录入，形成了一整套闭环。
效率
在运维工作中，有效地支持上线、变更、故障处理等操作也是重中之重。然而由于缺乏中间件团队，我所在的部门没有统一的MySQL使用习惯，这个团队做一套管理体系，其他的团队还有一套，更不要说公司内其他部门重复造出来的“轮子”。方案也是千奇百怪，往往接手的业务存储部分都没人敢轻易动手。NoSQL体系有一套，但是仅限于造轮子的团队附近的几个团队使用，仅用满足了一致性，无法支持事务。mq框架有一套，没有和业界其他队列组件对比，也就不发表评论了。最要命问题在于，业界纷纷支持docker容器进行扩容、发布变更、规范服务环境的时候，我们还停留在使用cgroup进行隔离。容器体系的开发本应该是运维团队牵头做起，但由于人力缺乏和领导短视，最终被研发团队抢去做，由于开发团队不是系统的使用者，自然很难设计出像样的容器平台。没有文件系统的namespace隔离，也经常发生研发之间互相改错文件导致故障的问题。不支持数据流程的管理，导致现网数据变更产生的故障一单接一单。
成本
成本的缩减不产生直接价值，但平台体量大到一定程度的时候，10%的带宽都意味着数以亿级的成本。如何节省带宽，看起来像是个技术问题，实际上是一个沟通的问题，一次成本项目往往需要牵扯5-6个团队进来一起做。
又回到为什么离职的问题上来
个人时间
国外的制度，拿到国内来用坏了的典型案例就是“弹性工作制”。10点左右到公司，晚上10点下班，这是闲下来的时候。在我毕业前后的实习阶段，每天下班的时间从来没早过11:30，回到家洗洗就睡，第二天睁眼就准备上班。11:30回到家里工作还未必结束，故障等着你，领导在微信群里的问候等着你，研发需要紧急上线等着你。
个人精力
一个人效率的管理往往不是时间的管理，而是精力的管理。一天的工作中除了各种同事私聊外，还有随时随地根本不需要你同意就可以拉你进去的群，在你思考问题的时候总能就是为了打断你而及时到来的电话，故障告警，老板提问，内外部投诉。在我的聊天工具里，滑屏到第5屏才会没有工作内容，工作群几十个，告警号十几个。这样的精力消耗总让人抱着手机发呆，刷着朋友圈等着告警的到来。你很难深入思考一个问题超过2分钟，因为一直在被打断。
能力培养
在前天跟总监的离职沟通中，总监建议我先转去另一个边缘一点的组，凭借我对基础框架和流程的熟悉去”带带“他们。先不说”带带“别的组，是不是有点过于看得起自己团队的技术能力了，技术这个东西如果能用熟悉一两个框架概括的话，不可能发展到今天这个高度。不得不说领导对于技术的理解有些让我瞠目结舌。个人认为，知识体系和学习能力才是竞争力，经验在现在这个时代一点也没有竞争力，要论经验，你不可能比未来的AI更有经验。
总的来说，离职的原因是对于现在的时间安排、能力提升通道不满，时候后想想如何提升自己的”硬实力“了。
