zoukankan      html  css  js  c++  java
  • iOS崩溃治理--流程制度篇

    对于崩溃治理,千万不要想着一个人单打独斗把所有事情都解决了。

    原因有两点,一是涉及到跨团队的情况下,一个人不能解决所有问题。二是,即使你一个人能搞定,那也会让你精疲力尽。

    因此最好的方式就是建立一个相关的指标和制度,让所有的相关方都参与到整个崩溃指标治理的环节中,让整个流程自行运转,而你则可以解放出来,做一些更有意义的事。

    那么要如何建立一个相对完善的制度呢,以下是我个人对于崩溃治理流程制度的一点见解。

    明确目标:

    要制定相关的流程,首先要有明确的目标。目前的App崩溃率是多少,要在什么时间点达到什么样的水平,如何评价目标的完成度,这些都是在一开始就要确定清楚的问题,明确了之后才可以制定下一步的计划。

    事前-灰度:

    最好的医术是医治于发病之前,同理,最好的崩溃治理就是预防崩溃。在有灰度功能的情况下,在发版流程中加入灰度的阶段可以极大地减少新增崩溃。假设你所在的项目每个月发一次版,那么正常来说应该能加入两轮灰度。可以在第四周开始的时候限制研发只能进行bug修复,此时进行第一轮灰度,灰度三天后,此时如果有大的新增崩溃正常已经暴露,然后修复相关问题,进行第二轮灰度。要是发版周期更短的话,可能就只能进行一轮灰度,一轮灰度一般情况至少要两天,并且要有一定的用户量。

    如果没有灰度功能的情况,或者说发版周期很短,可能根本没有空余时间去进行灰度。那这时候只能利用AppStore本身的放量功能了。可以和QA制定一下放量节奏,避免App更新后发生大面积崩溃。

    事中-patch&换包:

    App推送到AppStore开始放量后就属于线上问题了,如果崩溃量比较少我们当然可以等下版本再修复,但崩溃量比较大的情况一般就只能发patch修复或者换包了。

    那这个标准要怎么定呢,什么情况下需要发patch,什么情况下需要换包,需要从哪几方面来评估。建议大致可以这么定,单个崩溃达到指标的三分之一的时候就需要patch处理,达到一半以上的时候就进行换包。当然还得考虑其他方面,比如说这个崩溃是否能patch处理,patch生效的延迟是否会影响到这个崩溃的修复。

    发patch的流程也要制定,评估该由谁来发patch(责任人),需要周知到哪些人,patch的验证测试,以及patch的放量流程。同理,换包也是一样的,需要一个完整的流程。

    事后-推进崩溃修复:

    对于下版本再修复的崩溃,我们也需要一个流程去跟进,尤其是在有跨团队协作的情况下。建议可以通过工单或者bug的形式分配到对应的责任人,每个崩溃定下修复的时间点,若是不修复或者短时间内不修复也需要说明原因,这样就不需要单独设定一个流程。

    当然,有的童鞋会说,流程上的事情我根本推动不了,更何况还要跨团队制定流程。对此我的建议是,你可以先将整个流程的梳理明白,产出相关的文档及推进计划,然后去寻求直属上级的帮助。你的KPI归根结底会变成老板的KPI,当你有一个详细可行的计划,老板是没什么理由不支持的。

    有了完善的基础设施和流程之后,我们就从崩溃治理的苦力活中解放出来了,这时候我们就可以去做一些真正有技术的活了。关于这部分,我们下一篇再聊。

  • 相关阅读:
    年末反思
    Flink运行时架构
    Phoenix 启动报错:Error: ERROR 726 (43M10): Inconsistent namespace mapping properties. Cannot initiate connection as SYSTEM:CATALOG is found but client does not have phoenix.schema.
    Clickhouse学习
    Flink简单认识
    IDEA无法pull代码到本地,Can't Update No tracked branch configured for branch master or the branch doesn't exist.
    第1章 计算机系统漫游
    简单的 Shell 脚本入门教程
    开源≠免费 常见开源协议介绍
    MySQL 视图
  • 原文地址:https://www.cnblogs.com/bigly/p/14227657.html
Copyright © 2011-2022 走看看