在互聯網公司，最明顯的一個特點，那一定是加班。沒有最猛，只有更猛，我們知道的有996、007、大小周，但我們不知道的還有很多。那互聯網團隊為什么總是加班呢？并且總是加班很晚呢？

大概原因有三點，業務迭代快、人力資源少、產品問題多。對于業務迭代快，這個沒有辦法，大家都是在敏捷開發、持續集成、持續交付；對于人力資源少，這個似乎也沒有多少辦法，現在都是在裁員、1人當1.5人用；對于產品問題多，這個有辦法，只要做到這三點，別的不說，少加班是肯定的。

要保證產品問題少，其實也就等價于保障產品高穩定、高可用，總的來說就是這三點：完善的研發流程機制、較好的系統架構設計與實現、良好的個人質量意識。為什么是這三點呢？

我們來看看一個產品是怎么產生的，在需求確認之后，由研發進行技術選型、架構設計，然后進行開發、測試、上線、運維。這整個過程就是研發流程，核心抓手就是系統的架構設計和實現，核心影響因素就是開發者。

從研發流程機制來看，包含這幾點：

1.在設計階段，需要進行方案的技術評審；

2.在開發階段，遵循團隊內的分支模型，代碼需要進行代碼評審；

3.在提測階段，要寫單元測試并且運行通過；

4.在測試階段，要進行全面的場景覆蓋測試、接口測試；

5.在發布階段，使用灰度發布或者藍綠發布的方式逐步上線；

6.線上出現問題，立即回滾。

從系統的架構設計和實現來看，包含這幾點：

1.技術選型，總的來說就是選用組件的功能滿足度、可擴展性、性能、開發難度、社區活躍度這幾個方面去進行考慮。底子特別重要，因為所有的業務都是在這上面運行起來的，一旦有問題，整個都玩完了，重構的成本也是特別大。正如萬丈高樓平地起一樣，選用的材料不好則崩塌是瞬間的事兒；

2.架構選型，總的來說就是SOA、微服務、無服務。SOA架構就是將單體式服務進行拆分，由不同的團隊開發不同的服務，再通過ESB企業服務總線連接起來；微服務架構就是把業務的每個服務模塊原子化，由不同的團隊開發維護上線不同的服務，服務與服務之間通過MQ消息中間件或RPC遠程調用連接起來；

3.系統設計，系統設計總的來說就是少依賴、不依賴、分布式、能降級。少依賴指的是各個模塊之間盡量是拆分原子化的，因為一旦相互依賴，在開發、測試、上線、回滾這四個環節也是相互關聯的，牽一發而動全身，這也是為什么我們拒絕單點應用，因為里面全都是各種依賴。我們希望少依賴，最樂觀的情況就是完全不依賴，這時候在研發流程的每個環節都是獨立的，各自迭代就好。分布式指的是將把服務分散在多個地方，在分擔用戶請求壓力的同時，也相當于是做個保底，不至于一個服務掛了就全完了。能降級指的是在業務出現問題時，能有弱一些的解決方案，不至于讓用戶完全不能使用產品。

從良好的個人質量意識來看，包含這幾點：

1.積極思考需求價值，需求最終是交付給用戶的，研發人員也是用戶之一，因此在實現需求時，除了可行性之外，也要更多的思考價值，避免做了很多無用功能，最后又砍掉。；

2.技術設計時思考可擴展性。業務是持續迭代的，除了產品經理要考慮未來功能的演進，研發人員在設計接口字段時也要設計的很靈活，用以支撐未來業務的擴展，不至于到新功能開發時，還需要推翻從來；

3.進行充分的自測和單元測試。測試人員一般進行的是黑盒測試，只有研發人員對代碼是最熟悉的，最清楚代碼邏輯的，因此通過充分的自測、單元測試能提高產品質量。

4.對一切抱有敬畏之心。保障產品的穩定性是開發人員最基本的素質，不以業務繁忙、個人情緒為理由而忽視對產品質量的保障，這點其實是最難的，因為我們往往都會受各種外界因素影響，以及技術真的發展演進太快了、有時候會出現計劃趕不上變化。

總的來說，要保證產品高可用、低風險，只要做到了完善的研發流程機制、較好的系統架構設計與實現、良好的個人質量意識這三點，那就是妥妥沒問題的。聽說咱互聯網人月收入五萬，那也能有機會過的像五萬，而不是每天都996、007，埋在電腦前碼代碼、修Bug啦～