16/17年，Kevin对管理层有个要求，每月写一篇文章，激励团队、自省不足。
回到我自身，虽然坚持的还可以，但现在再把那些文章拿出来，可以说是不堪入目😭，每个月都要看领导写这么烂的激励文章，能坚持下去的一定都是真-好员工😍，再次感谢团队中各位伙伴的支持！
进入18年，虽然Kevin没有再要求，但写作的短板还得继续补。
今天就和各位聊一下18年我们部门的规划，规划的事情还真不少：SRE（可靠性管理）转型、研发效率工具支持、规范化自动化演进。
转化成结果指标有这些：
年度目标
其中，每一件事都非常有价值，也值得做的非常深入。
第一件，SRE转型
我把他放在第一，原因很简单，因为他最重要，无论是从公司业务还是对团队成长角度，如果今年团队只做一件事，毫无疑问我就选这件。
雅座业务是很典型的TOB类型，客户对稳定性要求极高，但过去几年IT行业互联网思潮所笼罩，无论技术还是管理思路，都是唯互联网化，互联网的那套搞法谁会在意服务宕机15分钟啊，更别说只影响局部客户的故障了。在加上项目压力大、技术宅高企，产品可靠性一直是个老大难问题。
17年，团队通过规范化、自动化的方式，让运维领域事故降低了70%。但并没有给公司带来实际价值，因为总事故数量，几乎比16年翻了两翻，这也让我坚定了团队的SRE转型决心。
SRE，全名是：Site Reliability Engineer，网站可靠性工程师，运维工程师的高阶形态。
最初由Google提出，阿里也在16年全面引入。
1、他们对产品的最终可靠性负全责，无论是数据库故障、代码BUG、甚至是第三方公司接口出了问题。
2、犹如顶级守门员要能统帅后防线一样，SRE团队需要协调研发、质控、架构，互相补位&协作，最终为公司交付坚固的后防线。
看似很高端，很牛逼是吧，其实我们已经开始动手了。一季度大王搞的代码监控，许超搞的应急预案，都属于SRE范畴。
虽然3月准备的SRE预算没有通过审批。但美好的事情躺在那里，总不能让尿憋死，那我们就利用现有的资源，再协调平台架构部的部分资源，把事情做起来，先看到一定程度的成果，也等雅座智能2.0的业务最终落地，相信属于我们的好运气总会来的。
对了，按照我们上周的会议，4月起，我们团队中的王欣、许超的考核方式，就是雅座智能2.0的事故数量了，一起加油！
无意中又符合了公司今年的人才战略：公司发展&个人成长，希望未来我们每个人都能转型成最专业的的SRE专家。
还剩下两件事，今天太晚了，就下次再聊吧，晚安！
网友评论