工程师意识
对有些同学来说,前两周是非常忙碌的两周。线上发生了几起事故,虽不全是我们部门的,但很多同学也在群策群力的一起去解决、覆盘、改进。同时,我们上周也对部门H1的冒烟、事故进行了回顾。
我们希望通过对踩过坑的深度覆盘,去发现需要改进的点,然后下次不再犯同样的错误。覆盘后发现,引发故障的原因中,变更占比100%,其中代码逻辑占比45%,方案设计占比15%。“变更是万恶之源”。我们对变更的管理,有没有达到10成的把握,这里面有流程机制的问题,也有各位工程师的意识及执行的问题。流程机制上,我们想了一些对策,接下来会对变更三大件(技术方案 + Codereview + 上线回滚方案)进行强执行。接下来想谈一谈工程师意识和执行的问题。
回首这些冒烟和事故,是不是我们在技术方案设计的时候多考虑一下异常情况,就可以避免这次事故?是不是我们在自测的时候真正测试到改动的功能点、前后对比是否一致,就可以避免这次事故?是不是我们在写每一行代码的时候、认真的了解到调用的函数的副作用和运行机制,就可以避免这次事故?是不是我们在使用中间件的时候对实现机制有更透彻的了解和确认,是不是我们在巡检的时候更细致的检查毛刺并追查原因,就可以避免这次事故?是不是我们没有想当然,改过的配置真正去调一下接口,是不是就可以避免这次事故?
在我看来,一件事情没有做到位,有两方面原因。 一方面,是没有这方面的意识,不知道应该这样去做,如何去做。 另外一个方面,就是偷懒了,心存侥幸,但我们并不会一直这么好运。根据墨菲定律,该发生的一定会发生。
对于工程师意识,百度已经有非常好的总结了,希望大家都每个字每个字的认真研读,一个合格的工程师应该具备怎样的意识。这都是前人的智慧,我们应该把它传承下去。
- 质量意识
- 流程意识
- world class procedure:用流程解决具有共性的、重复性问题,提高效率
- 要对自己的工作质量负责,不要期待别人来发现自己的问题
- 不要“想当然”:
- 不要默认“没问题”,而是缺省认为“有问题”;“肯定没问题”一定有问题
- “我以为他们已经开始做,但我也没有跟他们确认一下”—导致项目延期
- “我以为这个接口是这样定义,但谁想到是那样的”—导致程序崩溃
- “我以为发出邮件,他肯定就知道了”—实际上,他/她根本不在相应的邮件列表中
- 自我管理,自我推动
- 每件事情都有完成时间表,给自己一个约束,给别人一个承诺
- 每件事情有始有终,设立一些里程碑,在里程碑上检查进度,主动向其他人通报进度
- 当面沟通,电话沟通,召集会议都是有效的形式,但要留下文字
- 如果没有效果,应让更多人知道,尤其是你的老板和对方的老板
- 杜绝“可能”,“大概”,“应该”这样模棱两可的用词,而是用准确的数字和事实来论证
- Case study是一种文化,从事故中吸取经验教训
除了意识之外,我们还希望我们的工作伙伴有什么样的特质?
- 靠谱:凡事有交代,件件有着落,事事有回音
- 别人交办的事情,请第一时间给出预计完成的时间点。
- 过程之中注意按时通报进展。
- 如果预计要延迟,延迟多久,提前多久通报。
- 如果请求别人做事情,请给出期望完成的时间点。
- Ownership:高度负责,结果导向
- 对自己的代码质量负责、线上系统负责,确保结果
- 对交办的事情负责,确保结果
- 开发质量的保证,是自己的职责,不是测试的职责。写优雅、可维护的代码是自己的追求,决不妥协。
- 二八原则,确保自己的精力在解决主要问题,拿主要的结果
- 学会时间管理,4象限安排工作优先级,确保重要结果产出
- 工程师的核心竞争力就是解决问题的能力,不管你用什么方法
- 认真负责,思考全面,提前计划,步步为营
- 自驱自发:我的工作我做主
- 不要等别人为你分配任务,你就是自己的老板
- 主动承担更多的职责、主动学习更多的知识
- 自己尽力都搞不定的事情及时寻求帮助
- No Excuse,实事求是:不怕犯错,不找借口,主动反思,持续改进
- 主动沟通,善于协作
- 报喜亦报忧,确保协作方信息的及时性、有效性
- 主动语音聊,电话聊,跟进聊
希望我们的工程师,都具备以上工作准则,作为球队的不可或缺的一员,各自发挥自己的才能,一起赢!!!