本文介紹了企業網際網路開發及運維的一些實踐，深入剖析了網際網路專案開發及上線過程中的各種痛點及解決之道。
一個網際網路專案的上線並不是那麼容易，需要經過很多的環節：從伺服器的準備開始，緊接著是業務系統的搭建，搭建的過程中涉及到作業系統、依賴中介軟體、應用部署、配置修改等眾多事情；搭建完畢後，進行業務的線上驗證及各種場景的演練，並進行高併發的壓力模擬測試，找出效能瓶頸，並不斷進行問題修正、架構調整；最後進行災備的演練，整理好自動化指令碼，然後挑選災備環境的某一組進行上線試執行，迎接上線執行真實使用者壓力的考驗。
回想每次新專案上線的過程，每次都是一次痛苦的折磨。花費這麼長時間，根源究竟是什麼？答案就是這裡面太多的環節都是依賴人工去處理。那麼我們該如何縮短交付週期呢？
回到大家手上的網際網路專案，當專案上線後，是不是就萬事大吉了呢？慶功後，更多的事情才慢慢到來，隨著業務的開展，使用者量漸漸增加，高併發的場景也開始凸顯。由於只是關注了業務系統本身的上線，與之相關的外圍支撐系統並沒有建設，這種狀況下，根本無法瞭解系統的內部執行狀況。當前到底有多少使用者在訪問系統、每臺伺服器正承受多大的壓力、當前的業務量到底是多少？我們可以思考下，淘寶做雙11活動的時候，交易量是如何統計的？京東做618活動，實時流量又是如何統計的？我們應該建設哪些外圍支撐，才能做到系統不是黑盒？
當線上業務系統出錯的時候，是不是經常遇到無從下手的情況？這是因為隨著業務規模的不斷擴大，線上系統變的錯綜複雜，就像圖中的電線一樣，稍有不慎，就會起火！可能是網路問題、環境問題、程式碼問題、第三方API的問題等等，想要定位問題需要各種不同的技術棧，呼叫鏈路的追蹤，沒有科學的依據，幾乎不可能。
當線上出現的問題排解的差不多了，業務也穩定了，新的問題又來了。使用者的活躍帶來了流量的井噴式暴增，稍有不慎就會導致系統崩塌。這個時候，需要進行及時的擴容，拯救系統。但往往事與願違，機器準備不到位、環境部署不夠快、業務擴容不及時，導致擴容的成本居高不下。
或者採取了自認為“明智”的討巧做法，借用其他業務線的機器進行了擴容，但是你的業務系統跟兄弟系統環境是不一致的。新業務的侵入，導致了其他業務線環境的改變，反而造成了別的業務線癱瘓，真是城門失火、殃及池魚。我們急需一致化的環境進行擴容，Docker是我們的救兵。
面對如此多的問題，可以想象團隊的狀況會是怎樣的？團隊整天忙於救火，壓力非常大。很多時候為了救火而救火，拆了東牆補西牆，程式碼更是純粹為了解決問題而堆上去的，程式碼管理混亂，技術積累缺乏……
在這種技術積累的情況下，老闆又要開啟一條新業務線。由於沒有統一的專案模板，導致每次專案啟動都是底層程式碼都要重寫一遍。模組封裝不夠，導致本可以公用的模組，每個團隊都要重新封裝一次，研發資源的重複投入，使得研發成本居高不下。
為了使一切更規範起來，我們需要一個穩定的底層支撐平臺，保證業務的快速發展。做到快速開發新提出的需求，不斷的迭代小版本，開發的過程中有一些通用的模板和經過驗證的技術元件直接套用。開發完成後，能夠快速部署上線，小版本持續整合。上線以後服務不要掛掉，出現問題能夠快速定位。流量暴增的時候，能夠及時感知，並實現快速擴容。服務狀態可以不斷檢測，掛掉的時候，最好能夠自動重啟……
我們再來看使用平臺的價值和收益，首先持續整合的過程更加順暢，其次平臺的自動化將使運維人員的成本降低，再次基於DevOps的理念，將使得開發和運維在日常工作中高度協同，自動化的流程，讓一切變得規範，新版本的迭代更快更強，線上執行的更加穩定可靠。
iuap平臺支援DevOps全生命週期管理，並提供了對應工具支撐。提供了DevOps的最佳實踐和工具使用說明，提供元件庫對研發成果進行管理。保證編碼、構建、測試、預釋出、部署、監控等各個環節的持續進行。
對於快速開發，提供了一系列的開發工具、框架與元件、後端示例程式碼、前端模板等。並通過官網文件，進行知識的傳遞和反饋交流，社群化的響應開發者的各種難題。
想要解決系統黑盒的問題，我們通過收集瀏覽器端使用者點選情況和收集Nginx日誌的方式，以索引庫的方式進行效能資料儲存，最終對大資料進行分析，展示相應的業務報表，視覺化的檢視系統的各項執行指標。
線上出錯，我們通過收集伺服器端應用效能資料的方式，實時展示應用的呼叫拓撲圖，並根據出現異常的請求，進行下鑽，定位出具體出現問題的程式碼。
Docker的映象一致性，將業務執行所需的作業系統、依賴環境、業務war包等都統一封裝到了一起，應用部署的時候，直接拉取映象即可。業務規模小的時候，只需啟動少量容器，業務規模上來後，可以執行擴容操作，再次拉取映象，以Docker的形態啟動更多的應用容器例項。從此不再擔心大流量來襲時的束手無措。
