对于崩溃治理，千万不要想着一个人单打独斗把所有事情都解决了。
原因有两点，一是涉及到跨团队的情况下，一个人不能解决所有问题。二是，即使你一个人能搞定，那也会让你精疲力尽。
因此最好的方式就是建立一个相关的指标和制度，让所有的相关方都参与到整个崩溃指标治理的环节中，让整个流程自行运转，而你则可以解放出来，做一些更有意义的事。
那么要如何建立一个相对完善的制度呢，以下是我个人对于崩溃治理流程制度的一点见解。
明确目标：
要制定相关的流程，首先要有明确的目标。目前的App崩溃率是多少，要在什么时间点达到什么样的水平，如何评价目标的完成度，这些都是在一开始就要确定清楚的问题，明确了之后才可以制定下一步的计划。
事前-灰度:
最好的医术是医治于发病之前，同理，最好的崩溃治理就是预防崩溃。在有灰度功能的情况下，在发版流程中加入灰度的阶段可以极大地减少新增崩溃。假设你所在的项目每个月发一次版，那么正常来说应该能加入两轮灰度。可以在第四周开始的时候限制研发只能进行bug修复，此时进行第一轮灰度，灰度三天后，此时如果有大的新增崩溃正常已经暴露，然后修复相关问题，进行第二轮灰度。要是发版周期更短的话，可能就只能进行一轮灰度，一轮灰度一般情况至少要两天，并且要有一定的用户量。
如果没有灰度功能的情况，或者说发版周期很短，可能根本没有空余时间去进行灰度。那这时候只能利用AppStore本身的放量功能了。可以和QA制定一下放量节奏，避免App更新后发生大面积崩溃。
事中-patch&换包：
App推送到AppStore开始放量后就属于线上问题了，如果崩溃量比较少我们当然可以等下版本再修复，但崩溃量比较大的情况一般就只能发patch修复或者换包了。
那这个标准要怎么定呢，什么情况下需要发patch，什么情况下需要换包，需要从哪几方面来评估。建议大致可以这么定，单个崩溃达到指标的三分之一的时候就需要patch处理，达到一半以上的时候就进行换包。当然还得考虑其他方面，比如说这个崩溃是否能patch处理，patch生效的延迟是否会影响到这个崩溃的修复。
发patch的流程也要制定，评估该由谁来发patch（责任人），需要周知到哪些人，patch的验证测试，以及patch的放量流程。同理，换包也是一样的，需要一个完整的流程。
事后-推进崩溃修复:
对于下版本再修复的崩溃，我们也需要一个流程去跟进，尤其是在有跨团队协作的情况下。建议可以通过工单或者bug的形式分配到对应的责任人，每个崩溃定下修复的时间点，若是不修复或者短时间内不修复也需要说明原因，这样就不需要单独设定一个流程。
当然，有的童鞋会说，流程上的事情我根本推动不了，更何况还要跨团队制定流程。对此我的建议是，你可以先将整个流程的梳理明白，产出相关的文档及推进计划，然后去寻求直属上级的帮助。你的KPI归根结底会变成老板的KPI，当你有一个详细可行的计划，老板是没什么理由不支持的。
有了完善的基础设施和流程之后，我们就从崩溃治理的苦力活中解放出来了，这时候我们就可以去做一些真正有技术的活了。关于这部分，我们下一篇再聊。