2
来讨论一下，你们的产品有没有出过突发的线上事故，是怎么应急处理的？
source link: https://www.pmcaff.com/discuss/2701429699473472?newwindow=1
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
- *** • 产品经理
首先，快速定位事故影响范围，预估产生时间、对哪些用户有影响、是否有用户正在使用；并将这些情况告知项目负责人和直属领导；
然后，区分是功能性事故还是数据性事故：
- 如果对功能影响大，判断是否是新功能，是否会造成业务中断，大部分情况下尽快回滚；
- 如果是新功能且用户急用，需要保留功能，允许用户继续使用，并准备事后数据修复方案；
- 如果是数据影响，比如发送邮件、发送报表等，判断数据会流转到哪些地方，中止数据发送，并及时向相关人员告知情况，然后对数据进行修复；
最后，开发抓紧修复，产品抓紧给用户答疑指导。
- 某名声不太好公司商业化 • 产品经理
我们内部不用“突发”这个词去描述线上问题。只要你从业时间足够长、业务量足够大大、负责的产品逻辑足够复杂，那么遇到线上问题几乎是不可避免的。从认知上把“突发问题”改成“紧急问题”，然后设计常态化、流程化的应急策略。
- 问题发现：我是做商业化的，公司从广告投放到收入各个环节都建设了比较健全的预警机制，产品、运营、技术、QA都能第一时间观测到数据异常。发现异常后第一时间发到群组。
- 问题定位：相应的开发快速定位问题，定位后同步至群组。e.g. 单位周期内有超出阈值的广告创建失败，投放的技术需要第一时间介入，必要的话会组织上下游一起排查原因。
- 问题解决：设计解决方案，同步至群组，周知各相关方。如修复过程中影响用户体验，需要技术、产品等同学一起讨论决策方案；影响重大的话，需要升级沟通。方案确认后，修复线上问题。
- 问题复盘：问题对应的技术leader组织cs，事故责任划分，这是工作质量、绩效评判的依据之一。影响范围较大的话，由对应的产品发事故通报（我在目前的公司两年，发过两次通报）。
- 小地摊 • 原型仔
很严重的就回滚
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK