原始笔记是从《极客与团队》摘抄出来的若干小标题清单,部分项目符号是问号占位。这里把清单转成正常的列表,文字尽量保持原样。
当前保留内容
三大原则
谦虚、尊重、信任(HRT,Humility / Respect / Trust)。
一份出色的事后检讨(Postmortem)应该包含
- 简要
- 事件的时间线,从发现到调查,再到最终结果
- 事件发生的主因
- 影响和损失评估
- 立即修正问题的步骤
- 防止事件再次发生的步骤
- 得到的教训
关于”导师”
满足三个条件就基本可以胜任:
- 熟悉团队的流程和系统;
- 向他人解释事物的能力;
- 估计被指导的人到底需要多少帮助的能力。
最后一个条件或许最重要——你要做的就是给学生提供足够的信息:解释得太多或东拉西扯,学生未必会领情,他可能会直接忽略你,而不是礼貌地告诉你”我已经明白了”。
关于”开会”——五条小贴士
- 只邀请一定要参加的人;
- 开会前要决定好议程,而且要事先通知所有人;
- 达成目的后应提早散会;
- 注意别跑题;
- 尽量把会议安排在休息时间前后(比如午饭前后、下班前等)。
关于”保护团队”
- 写一份明明白白的任务宗旨,随时保持专注,知道哪些是目标、哪些不是。
- E-mail 讨论要有礼仪,保留归档;要求新人研读,防范”嘈杂的少数人”。
- 所有历史都要有记录——不只是代码历史,还有设计决策、重要的 bug 修复以及过去犯过的错误。
- 有效地协作:利用版本控制;代码改动尽可能小,方便审查;扩大”公车因子”,避免领地感。
- 修复 bug、测试、发布软件要有清晰的政策和流程。
- 降低新人加入时的壁垒。
- 依赖基于共识的决策;在无法达成共识时,要准备好化解矛盾的方法。
经验之谈
不管技术债务有多少,团队也永远不应该花超过三分之一甚至一半的时间和精力去做防御性的工作,否则就等于政治自杀。
后续可补的方向
- 把”事后检讨”模板套到自己经历过的真实事故上,看哪几项最常缺
- “公车因子”的具体度量方法(关键模块单点风险)
- 对 HRT 三原则做一份对照行为清单(哪些行为算违反 HRT)
FEATURED TAGS
Git
Cheat Sheet
Markdown
Tools
C++
Linker
Thread
Linux
TCP
Network
GDB
Debug
leetcode
链表
WSL
Ubuntu
Windows
Linux Kernel
GCC
Android
adb
Troubleshooting
Profiling
Sanitizer
glibc
MySQL
Database
Python
curl
Build
ELF
clang-format
CMake
Graphviz
Performance
vcpkg
Protobuf
排查
速查
内存
STL
调试
性能分析
性能
读书笔记
方法论
架构
网络
Timer
mbedTLS
TLS
安全
负载均衡
脚本
工具
LRU
二叉树
BST
中序遍历
回溯
二分查找
优先队列
排序
旋转数组
jenkins
部署