案例分享我们的一次线上事故复盘

　　问题出现了并不可怕，只要我们追本溯源，找到问题根源所在，科学的解决问题，合理的制定流程，就能离成功更近一步。
　　线上事故，这应该是产品经理最怕的事情。很不巧，我的产品这几天正好遇到了线上事故，在处理完问题之后，我对事故进行了复盘，警以为戒，希望各位轻拍。
　　“小凡，你看微博有用户反馈xx问题。”
　　每次听到运营妹子的声音都会有种心惊肉跳的感觉，因为这悦耳的声音背后往往意味着用户吐槽，意味着线上bug。这不，昨天刚发布的版本出现了问题，用户怒了。
　　问题是什么
　　我负责一款以内容为核心的工具型应用，在我们最新发布的版本中，我们对内容展示页面进行了优化，索引词会高亮显示以帮助用户更好地查看、理解内容。
　　但是上线后用户反馈索引词的顺序有问题，全部提至了句首，导致句子全部错误，无法正常阅读。
　　问题在哪里
　　程序设计错误
　　程序猿在做索引词高亮处理时，程序逻辑设计不当，虽然对索引词加了高亮，但是处理高亮词是将整个句子视作一个词条进行处理，提取索引词后进行高亮处理，将高亮词放回时，替换其到index0的位置，导致索引词显示在句首。
　　功能测试遗漏
　　测试同学在做模块化测试、全功能测试时，并未测试到该细节，导致该bug发布上线，当用户反馈后才补充了内容测试相关case。
　　存在问题的原因
　　新代码设计不合理
　　旧的逻辑是按照空格进行字符串的分割，将句子拆分为一个个词，再去判断是否有索引词，如有则提取出来做高亮，而我们本次处理的内容由于语种特性并没有空格。
　　程序猿并未考虑新需求的不同之处，依旧使用统一的处理方式，导致新的语种内容在呈现上出现异常。
　　正常处理逻辑应该是不按空格进行拆分，直接判断例句中是否包含所查索引词，如有并作高亮显示。
　　提测单未写明修改点
　　按规范每轮单元测试，需将新功能、修改点、可能涉及的影响都写明，让测试同学知晓以便进行全面测试。但在开发同学看来本功能较小，并未在单元提测中单独标明。
　　测试未覆盖内容版块
　　测试针对新功能、UI和测试用例进行了测试，但是未考虑到本应用是重内容的应用，缺乏对内容的测试。
　　我们能做什么
　　安抚用户
　　定位问题之后，运营同学第一时间与微博用户联系，先表达歉意，再标明程序猿正在修复中，请用户耐心等待；同时发布正式通知，告知用户问题已经开始修复，我们将尽快发布新版本以解决问题。
　　紧急修复
　　在运营同学发布通知的同时，程序员立即着手修复该bug，并针对此前忽略的内容问题进行复查，自测通过后移交测试人员。测试通过后，请教研同学配合进行内容测试，确保内容相关展示无误。
　　尽快发版
　　苹果应用商店的正常审核流程是3至7天不等（必须吐槽），但是紧急bug刻不容缓，不能走此正常流程。面对极其重视用户体验的苹果，加速审核申请往往能帮你在数小时候审核通过。
　　必须让苹果知道你是非常重视用户体验的，而你的app现在出现了非常严重的bug，为了用户的体验你必须立刻发布一个版本，这样加速审核通过的概率会很高。审核通过后，立即发布上架让用户更新，这时候用户更新说明也是至关重要的，值得用心去写。
　　我们应该做什么
　　上面几个步骤重在解决已发生的问题，而在我看来更重要的是知道如何规避未来的问题。这就涉及修改流程了，我们是这么做的：
　　1。两端开发人员系统梳理代码逻辑，差异点、疑问点及时进行沟通、确认；
　　2。版本正式开发前，增加技术拆分会，确认开发思路和实现逻辑；
　　3。iOS开发人员加强代码交叉
　　4。iOS开发人员加强自测，自测中加强与安卓端对照；
　　5。测试人员增补内容测试用例，加强两端对照测试；