系統的潛在問題與不確定性
在軟體工程裡，任何產品的研發，如果持續時間很長，人總免不了疏忽、犯錯，導致程式碼存在缺陷，電腦當機崩潰，網路堵塞中斷……如果一項工程需要大量的人員共同研發某個大規模的軟體產品，並使其分佈在網路中的大量的伺服器節點中同時執行，隨著專案規模增大、運作時間變長，其必然會受到墨菲定律的無情打擊。
在系統迭代的過程中，如果將時間與工作量拉到足夠長的維度，那麼存在問題是必然的。這一點在大型的分散式架構服務上尤為突出。
在我的理解中分散式本身就代表著不確定性。
首先，分散式帶來了服務之間的不確定性，舉一個很簡單的例子，假如是一個人出去玩，那麼就可以很隨意的制定計劃，如果是很多個人呢？那麼不可避免地需要協調不同人之間的喜好與行程，這就是天然的不確定性。
其次，服務本身也存在不確定性，即使是我們自己，也很難保證心中所想的能夠貼合自己的內心或者需求，例如，我就經常熬夜到很晚，總是認為下一個五分鐘就能睡著。不過，相較於服務之間的問題，服務本身的問題還在可控的範疇內，甚至可以說一些問題原本就是為了讓步服務間呼叫而產生的。
那麼存在一個大規模且可靠的系統嗎？
馮·諾依曼在自複製自動機（Self-Reproducing Automata）理論中探討過，如何用一些“不可靠”部件構造出一個可靠的系統。
我姑且用周老師的話來解釋。
“不可靠”部件可以理解為構成生命的大量細胞，甚至是分子。由於熱力學擾動、生物複製差錯等因素干擾，這些分子本身並不可靠。但是生命系統之所以可靠，恰是因為它可以使用“不可靠”部件來完成遺傳迭代。這其中的關鍵點便是承認細胞等零部件可能會出錯，某個具體的零部件可能會崩潰消亡，但在存續生命的微生態系統中其後代一定會出現，重新代替該零部件，實現它的作用，以維持系統的整體穩定。
對於以上這段話，我想，每個人都有自己的理解。行業內絕大部分的前輩都比我更有經驗，在此，我也闡述自己的觀點，以供未來的自己對照。
在實習期間，G老師就曾對我說。
不必將需求與功能看得太重，對於我們來說，線上產生的一個問題，造成的損失，很有可能遠大於，完成的數十個甚至更多需求所帶來的收益。所以，重視穩定性。
當然，這段話在我的記憶中是隻可意會不可言傳的，因此我唯一能保證的，便是這句話不是原話，但意思到達即可。
作為勉強夠得上“大流量”與“高併發”的團隊來說，G老師表現得足夠謹慎，不過，在對我說這段話之前的幾個月，他就因為故障背過低績效。
淺談穩定性
一.對於系統而言，這段話給我帶來最直觀的一個思考便是穩定性也是系統的一部分。早在校園中，我就存在“健壯性”這個概念，我也曾思考系統的健壯性是不是就是穩定性呢？將所有可能的情況考慮在內是不是就不會再有問題？
有段時間，我很喜歡降維打擊這個詞彙，雖然有些不妥當，但我還是選擇用在這裡。不穩定、不確定，對於一個大型系統而言已經是必然存在的，那麼我們就不必去挑戰這種常識。健壯性的思考很好，它能避免很多問題、處理很多邊界問題，但這不是萬能的，甚至可以說，與我想象中的“穩定性”背道而馳。
在此插一嘴，我認為系統並非孤立存在的，而是使用者、管理員，A端、B端、C端與整個系統互動的全部過程，這都是系統設計過程中需要考慮到的。
系統的不確定性，沒人能夠保證的原因很重要的一點是，你無法確定使用者的行為在預先設定好的模型裡。
最直觀的一點便是，假如，你想要設計一個系統供殘疾人使用，那麼天然地你需要考慮到各類殘疾人可能存在的問題、他們可能做出的各類不同尋常的反應以及更多更細節的考慮點。
這意味著，你所設計的使用者行為模型必然需要契合這些需求，但你能不顧正常人的使用嗎？假如存在B端，那麼顯然你需要對不同模組“因地制宜”地設計。
我認為這就是一個很好體現我的想法的例子。
這同樣能引申出迭代的問題，經過足夠多的使用者行為測試，以及使用者習慣培養，即使是在某一個時刻的“完美”系統，也會在下一時刻不再“完美”。
談談“健壯性”與“穩定性”吧，我認為“健壯性”是將系統預設到了“健康”的境地，在此基礎上去處理各類不同的情況，先有了出現問題的場景，再透過設計去避免或提前處理。但“穩定性”則完全不同，你自然而然的將系統預設到了“危險”的境地，已經做好各類預案，甚至在問題出現時，你還沒有定位到具體出錯的程式碼或者服務，但你可以先透過預案解決，這是先有了一個較大範圍的處理方式，再去對出現問題的場景進行解決。這就是我認為兩者在一定程度上是背道而馳的原因。
再回到那一句話“穩定性也是系統的一部分”。也許會有很多人將穩定性視作一種手段，獨立系統而存在。但我認為，既然我們已經預先設定好了系統的不安全、不確定，那麼對其可能出現的問題場景做預案就是一種必然。二者是不可分割的，假如穩定性手段足夠多，能夠兜住系統出現的所有問題，令使用者行為與感知無法感受到故障的出現，那麼也不失為一種可靠的實現手段。
或者說的再直接一些，穩定性保障足夠完備的情況下，是不是也意味著系統足夠可靠呢？
二.對於團隊而言，穩定性的建設同樣存在於團隊合作之間。說實話，我並沒有統籌過一個團隊的分工以及各類事項，因此這一段話可以說完全是我的臆想，但我又覺得這是必不可少的一環。在我嘗試以G老師的視角來思考團隊時，第一個想法便是團隊與穩定性的關聯。我時常告誡自己，不要用孤立、片面的視角去看待問題，很遺憾的是，我在絕大多數的情況下沒有做到。
也許會有人認為穩定性只存在於程式碼實現的分支處理流程，或是某些開關之類。但團隊中每個人同樣在這一環中，不同業務域的輪崗、A崗與B崗的設立，這都是為了個人在團隊中的穩定性，這至少一定程度上保證了，團隊缺少了某一環，也能有人頂上。至於團隊氛圍、排班等等，我就不再過多贅述，也許某一天我對其中一項更有體會時，便會再次記錄下來。
但總結成一點，那便是穩定性建設，在一個團隊中是深入骨髓的，任何關係、安排都在一定程度上為它服務，甚至在一些組織架構良好的整個公司的視角也有一定的參考意義。
三.對於業務而言，穩定性是業務重之又重的斟酌項。業務的穩定，代表了公司的穩定，對於現在這個時間點，PDD以省打響了一炮。我認為其中不可或缺的一點便是“省”這個點對於使用者而言是確定的，也即業務層面上的穩定。如果有“省”需求的使用者，一定程度上無法避免PDD的吸引。對於品質、體驗，每個人都有自己的想法與標準，但對於一些確定的指標，這是無法變更的，這也代表了某些群體對於業務需求的穩定性。
當然，在穩定性上，有許多可以詳細拆解的部分，但如果想嘗試事事說盡，那也便少了只可意會不可言傳的藝術感。未來若我有機會再翻到這篇文章，希望我還能回憶起“話不可道盡”的留白想要表達的內容。