谁也不愿意发生事故，但是一旦发生总得面对，场景如下：
发生了应该干什么
- 快速止损：弄清楚问题原因，找到相关方，确定方案：紧急上线，数据修复。。。。。。
如果对方不配合，可说明事故严重性，可上升至更高层级
成熟的企业，都会涉及事故报告，事故定级，事故复盘。
事故责任归属这个环节很容易扯皮
- 如果是接口参数争议，需要翻越当时的约定文档
- 如果上游变动引起的，需要翻越上游变更记录，是否有通知改造的邮件
- 除非完全和外部系统无关，很多人在定责时都会"努力"寻找对方系统的弱点，
甚至可能扭转责任主次 - 由于存在3，对相关的文档一定会”嚼文嚼字“，有点文字狱的感觉
- 虽然责任有主次之分，但很多时候碍于情面，和稀泥，会各打五十大板
领导也很难
- 你肯定会想了解事故的影响范围：如发出去一封错误的邮件，你想知道有多少人会打开，
此时你需要知道历史打开率，很有可能，团队的人并不知道。。。 - 你肯定想知道这个事情发生的前因后果，于其他系统的交互细节，上下游关系，
但是有可能大家只是安于本职工作的螺丝刀，所以还是不知道。。。 - 你可能想知道这个业务是什么上线的：如果没有规范的项目管理，你可能也查不到。。。
- 如果是交接系统，你想确定是否是历史遗留问题，想查看系统的交接时间：
如果没有规范的交接流程，你可能还是查不到。。。 - 平时能力很强人，这一刻不一定具有危机领导力
- 当你在奋力寻找解决方案时，下班时间到了，我方疑似相关责任人走了。。。
- 你想收集各种信息时，屡屡失败的挫败感，莫名又必须压下去的心头怒火。。。
以下操作真的很重要
- 交接业务的交接时间
- 接口规范，一定要有文档留存，聊天记录会清除，不可靠
- 上游变动影响下游的，一定要邮件，群聊，单独知会，一定要一一到位
”不回复就意味着同意“是严重的耍流氓行为 - 对自己系统的核心指标一定要了然于心
发生能力峰值多少？
目前每天发多少？
系统处理的哪个环节最耗时？
核心页面的访问量大约多少？
邮件打开率大约多少？ - 和别人有交互的流程：尽量了解下边的东西，
别人为什么依赖我们？
拿着我们的数据去干了什么？
如果我们挂了，他们的灾备方案是什么？
他们的流量高峰是多少？
如果遇到突发流量，我们能干什么？ - 写给别人的交接文档：一定要力求准确，不敢保证的别瞎承诺
- 别人的接口文档有疑问的，一定要再三确认
- 对发生过的问题一定要修复：这次可能是个小问题，下次可能被领导抓到，就是个事故
网友评论