很多公司技術支援崗位的工作，如配置域名，部署環境，修改復位配置，服務重啟，擴容縮容，梳理和完善監控，根據開發的需要查詢日誌等工作，需要和開發進行大量的溝通，如什麼是外網域名，什麼是內網域名、A name、C name，防火牆規則該如何設定，作業系統等基礎環境需要什麼依賴。因為很多研發不瞭解運維的術語和知識點，導致溝通困難，效率很低。而且這樣的需求還很多，把運維壓的喘不過氣，佔用了幾乎所有的時間，但是開發的需求可能還是遲遲不能滿足。
這樣的公司可能遇到了以下問題：
- 系統架構過於陳舊，效能、可靠性無法滿足現有的需求；
- 原有IT架構不靈活，業務模組新增或變更帶來巨大成本壓力；
- 系統功能繁雜，結構紊亂，定製的程式碼與系統耦合性極高；
- 服務種類繁多，各種技術棧橫行；
- 人員流動交接不充分，新接手的團隊對部署環境不瞭解，只能做周邊的修補，不敢遷移 。
如何才能解決？答案是流程化、標準化、自動化、平臺化。
流程化
即主動梳理運維工作任務，形成標準化的操作流程，尤其是針對需要多人協作完成的任務，比如應用的釋出部署，把流程固化到流程平臺系統中，保證每個人執行都能按照流程嚴格執行，不會有哪些環節遺漏，而且當前的流程狀態對所有人都可見，能清晰的看到誰正在處理，處理人也會更主動儘快的完成該任務。
標準化
從架構角度按照應用類別制定應用的部署標準，比如Web型別的應用，服務化的應用（我們內部用的.NET Core），或者是比較新的微服務的應用（.NET Core等），部署指令碼和工具平臺按照約定好的規範進行設計開發(基於Kubernetes)，減少了因為應用種類繁多導致工具和平臺的複雜。
自動化
很多公司早期寫了非常多的指令碼，任務執行機到要執行任務的伺服器之間通過SSH免金鑰認證，再根據需要批量執行命令。隨著伺服器規模和應用數量的擴張，很快指令碼執行的方式無法滿足業務發展，難以理解，同一個型別的任務多個指令碼並存，存在誤操作，缺乏清晰的操作歷史記錄和回滾機制，即使後續替換了如Puppet，Saltstack，Ansible這樣的配置管理工具，但根本問題並沒有解決。
平臺化
平臺化一定要在前面三條的基礎上進行建設，如果沒有清晰的流程，明確的標準，平臺建設起來也只是自動化工具的整合，解決不了公司核心問題。
以下說的平臺化內容主要是PaaS平臺化，即主要從應用和中介軟體的角度，這裡不討論IaaS的內容。
PasS平臺化將問題的關注點從基礎資源上升到了應用層面，目標是提供一個幫助開發人員執行、管理應用的平臺，讓使用者更關注執行的程式碼（業務邏輯）。
PaaS能解決的問題：
- 應用聚合：如開發需要一個Redis，直接啟動一個Redis容器即可
- 服務發現、快速伸縮、狀態管理等
- 服務監控、恢復、容災
- 安全管控：不管什麼平臺，安全都非常重要，例如A應用可以訪問B,B不允許訪問A以及安全審計等。
- 快速部署。
隨著Docker容器技術的出現，讓我們有了更合適的工具建設PaaS平臺，具備了基於應用構建服務的能力。 在Docker容器排程框架上，我們自然選擇了Kubernetes平臺。Kubernetes具有資源排程、服務發現、服務編排、資源邏輯隔離、服務自愈、安全配置管理、Job任務支援、自動回滾、內部域名服務、健康檢查、有狀態支援、執行監控/日誌、擴容縮容、負載均衡、灰度升級、容災恢復、應用HA等。Kubernetes的核心是如何解決自動部署，擴充套件和管理容器化（containerized）應用程式。
下圖是一張最小化的PaaS 架構圖：
- 最上面的Ingress服務跟傳統的負載均衡器的功能類似，提供請求分發的功能,分為兩類： 對外提供API服務的API閘道器以及對外提供服務的站點,對外的API閘道器採用Ocelot 進行開發，Ocelot完成了對Kubernetes的整合工作，這個功能已經在我們的平臺上工作一段時間了，上個月把程式碼合併進入Ocelot主幹，已經可以通過Nuget包下載，具體參見 kubernetes 客戶端KubeClient使用及常用api。
- Service相當於後端Pod的一個代理伺服器，Service需要通過Ingress服務才能被外部Client訪問, Service 提供了服務的註冊和服務發現。
- Pod則相當於我們傳統的一個服務。
- 最小化PaaS平臺還用到了DNS元件，在內部服務執行起來之後，我們會通過DNS元件分配一個內部域名供訪問時使用。
Kubernetes 選用騰訊雲 TKE ，TKE 服務在叢集內預設啟用了基於騰訊雲負載均衡器實現的 l7-lb-controller，支援 HTTP、HTTPS，同時也支援 nginx-ingress 型別，可以根據業務需要選擇不同的 Ingress 型別。
平臺關鍵能力說明
- 應用持續部署，平臺實現快速、視覺化自動部署功能。支援對應用的快速、視覺化部署。使用者僅需在介面中選擇相應的映象和元件，並填寫簡單的配置資訊，點選部署按鈕，即可完成整個應用的安裝或者升級。
- 應用彈性伸縮，構建具有需求預測和容器按需供給能力的彈性伸縮子系統，具有基於應用的負載和資源情況進行彈性伸縮能力，以應對網際網路使用者高併發的特點，應對流量衝擊。其中，包括容器彈性伸縮、物理機彈性伸縮功能。
- 容器和元件的統一管理，從整體應用的角度出發，平臺不僅管理映象和容器，而是將一個應用涉及的所有元件均做了統一管理，通過對系統相關元件和容器統一管理，平臺將可以實現系統的全域性統一部署、配置、升級/回滾、監控、故障處理等功能。
- 高可靠性，容器的故障恢復，當伺服器當機時，平臺系統會自動在其它伺服器上重新啟動容器併為其分配資源，從而達到秒級啟動，恢復業務。保障業務不掉線，高可靠執行；
- 應用Docker化封裝，系統支援如下幾類常見應用：.NET Core、Jexus、Nginx、Redis、Mongodb等。
PaaS平臺功能元件
具體實施時，主要有幾個基礎元件需要開發：
- 映象管理，實際執行的應用映象由 “基礎中介軟體映象”+“應用包”+“配置” 自動構建，藉助於Visual Studio 2017/2019以及Visual Studio Code，以及微軟開源的Helm、Draft，通過標準化內部培訓，讓開發人員快速理解映象概念和製作映象以及開發流程；
- DNS管理，定製化公司內部使用的DNS管理平臺，對公司的DNS進行統一管理；
- 服務管理，需要定製化一套Kubernetes的Deployment模板，從Ingress到Service再到RC都定義在這套模板裡面，方便對容器進行擴容、縮容、刪除操作；
- 服務內Pod管理，屬於Kubernetes自有範疇，檢視Service內的Pod執行情況、Pod日誌輸出等功能；
- 日誌管理，將日誌輸出到公司的日誌平臺（如ELK平臺），對接研發人員排查問題、資料埋點使用；
- 監控管理，參考方案：cAdvisor + InfluxDB + Grafana/ Heapster + Grafana/Prometheus/Zabbix：https://www.cnblogs.com/Cherry-Linux/p/9144650.html。
雖然我們屬於創業公司，我們相信技術的力量，技術幫助我們實現業務的持續健康發展，從發展的初期就規避很多公司的一些困境，一箇中小企業做成這樣後，日常運維的工作量即可大量減少，兩三個人就能完成日常的應用運維工作，有興趣地話可以去挑戰一下。當然做完這些後，還只是一個小型的PaaS平臺，我們基於騰訊雲的TKE 平臺構建這樣一個小型的PaaS平臺。
如果是再複雜一點的PaaS平臺，應該還有哪些要繼續做的呢？環境管理：即一套平臺管理多套不同的Kubernetes叢集、安全管理、流程管理、計費管理等功能模組。還有因為規模增加和更高的可靠性要求，對應的網路，IO等各種優化。其實還有很多功能就不一一列舉了，可以根據自己的實際情況新增功能模組，設計有自己公司特色的PaaS平臺。