iOS崩潰治理-開篇 - ⎝⎛CodingNote.cc ⎞⎠

去年我開始負責iOS崩潰治理的工作，從原來的萬分之五崩潰率，一直到現在的萬分之一左右的崩潰率，期間踩了很多坑，因此想和大家分享一下，希望能對大家有所幫助，也歡迎大家私信交流。

如果你打算開始治理崩潰的話，建議你先想一下以下的問題：

如何高效地去定位修復崩潰？

修複線上收集到的崩潰，可以說這是無法避免的體力活，大部分的崩潰事實上並不複雜，都不難解決，但怎麼快速定位是個問題。

大部分的崩潰堆棧很清晰，通過日誌我們可以很容易定位到有問題的程式碼，但有些崩潰日誌，很可能只有一堆系統相關的堆棧，很難對應到業務程式碼。對於類似情況，有沒有相關的應對方案，決定了你的崩潰修復效率。

除了解決線上收集到的崩潰還要做些什麼？

解決線上收集到的崩潰是必須的，但這只是個必要不充分條件。如果你只是case by case地解決線上崩潰，那很快你就會疲於奔命，被困在無休止的體力活當中。

原因主要有以下幾點：

1，你所處的項目比較大，可能涉及到好幾個團隊的協作

2，每次發版都可能引入新的崩潰

3，後端的改動也可能引起線上崩潰

4，新系統的發布也可能引起問題

如何推動跨團隊的協作？

對於一個比較大的App來說，通常都會涉及到多個團隊的合作。比如說，登錄SDK，IM,日誌上報等功能，一般都會有專門的團隊負責。也就是說，線上的某個崩潰很可能要找另外一個團隊的人解決，即使你知道怎麼修復，也很可能沒許可權。這時候僅僅靠你去協調是不現實的，這會耗費你大量的精力。

每次發版總會有新的崩潰要如何解決？

新需求總是會伴隨著或多或少的崩潰，每次發版都會有著上漲的風險，畢竟研發和QA也都是普通人，不可能不毫無遺漏。要如何降低這種風險，以及在問題發生之後如何及時止損。

線上突然爆出問題該怎麼辦？

線上突然出現崩潰的情況其實並不少見，尤其是和服務端交互比較多的App，甚至是一些有網路請求的三方庫也可能引起類似問題，這時候要怎麼及時發現問題, 如何及時修復止損。

有沒有一勞永逸的方法？

這是終極目標，但是很難，因為項目總在迭代，即使你不迭代（不迭代這項目也沒有什麼價值了），系統也會更新。但即使做不到一勞永逸，我們是不是可以找到一些方式，讓我們只需要花很少的時間來維持線上穩定。

對於這些問題，從手段方面，我分為三種，基礎設施，流程規範，技術防控。從時間點上，又可以分為事前，事中，事後。後續我會從這些方面來跟大家分享自己的一些經驗，有些內容可能在大家的項目中已經實現了甚至是做的更好，有些內容可能是你所欠缺的，希望能和大家多多交流。