高校外包公司自動化部署生存指南

**菜你都做好了，如何端給使用者？**

## 前言

《外包公司，等你長大》這一篇預告很久了，一直沒有成筆，今天寫的可以算是其中一小點，只是聚焦於應用分發和交付的問題，為什麼會寫這一篇，**這一切，都要從一隻蝙蝠說起。。。**

因為疫情的緣故，高校最近密集上了包括健康打卡、不見面辦理、視訊會議和網路教學等相關的應用。各個資訊化部門也乘機在裡面夾帶了各種私貨，包括推廣某些平時很難推動的平臺，對師生進行資訊素養教育提高等等工作。每一次危機，其實都伴隨著機遇，就看你如何能夠及時把握。

這些應用都有高併發高流量的需求，而且時間緊，需求變化快。如何快速平穩交付是一個比較大的問題。

在這裡，雲平臺也冒出來了。高校原先是比較排斥雲的，不知道什麼緣故，大家總認為，物理上在學校內部，才是自主可控的。但是這次不同，師生都在校外，只有雲和CDN才是最接近使用者的。

雲端儲存和CDN有毒，用了就停不下來。

然後在我最近跟他們交流中，我發現了一些應用交付上的問題。

大部分外包公司，都還是很原始的手工部署，而且部署人員的技術水平和安全意識在公司整體屬於比研發低一點。

如果從DevOps來說，這也有研發的鍋。研發開發完成，哪管你運維人員怎麼部署。

外包公司總是向我們拿更多的CPU、更多的記憶體、更高的空間佔用，拿硬體負載均衡，拿Oracle。因為這些在我們這邊是增加成本，但是對他們是節省成本，節省軟體框架最佳化的成本。外包公司還會向我們拿更多的系統維護停機時間，更長的小版本更新週期，更長的作業系統和基礎軟體更新週期。這些在我們這裡是影響使用者體驗和系統安全的，讓資訊化部門被使用者打低分的。對他們來說，還是節省成本。為了效能，CPU、記憶體等等我們也會願意給，但是這要有一個度，因為一個應用，如果不從框架或程式碼方面去做最佳化，給多少資源都是沒用的。甚至於，有些應用，我們想給更多的資源，但是他消耗不了。

所以我認為，如果可以，外包公司請儘快遷移到自動化部署上去吧。如果能直接二進位制打包War、Docker給我們更好，因為現在儲存實在太便宜，我們不再需要為了解決空間佔用而帶來的各種依賴共享、動態載入、各種不同版本化的庫。然而大的外包公司，歷史包袱重，轉身很難，如果一個老的CTO，只求穩不尋求技術更新，那新技術就很難推進。遷移肯定是有陣痛的，短期內成本是上升的，但是長期會以另外一種形式補貼你。對客戶來說，能給你提意見的才是優質客戶，批評越重，那都是真愛，希望你成長為101年的企業，畢竟你死了，大家都不好過。

## 自動化部署

> 我們維護400個學校的2000臺機器

這時候更需要自動化部署，自動化部署具有高效率和較快的部署能力，而且不容易出錯。不同學校不同的配置檔案進入.gitignore隔離。當然，自動太自動了，指令碼出錯影響面也很大。這是另外一個問題。

比如，自動化，也不推薦只用一臺主控機。我們一般自動化部署，會有Test機器列表，Staging機器列表，Production機器列表，透過不同指令碼跑，假設你使用工作用機來當主控機，所以你所有機器列表要對主控機都開通SSH防火牆，然後有天你手抖了，正在Test上修改配置，然後跑了Production指令碼，就悲劇了。所以一般都建議，主控機根據不同環境分隔開來。

## Test或者Staging環境

這些環境應當和Production環境一致，然後定期同步資料庫和共享檔案。現在一般很少這麼做，成本較高，或者Production環境部署10臺，但是Test環境才2臺，而且資料不一定同步。這些都會造成一些問題，比如壓力測試可能就做不了，查錯還是OK的。

多個環境一定要非常小心，特別是rsync，mysqldump，再困再累，也要對命令列左右路徑double check一下。

## 小版本升級、遷移正確的開啟方式

如果完全按DevOps的理念，不可變伺服器，每次升級，都重新構建一臺全新的伺服器，然後扔掉舊伺服器，這個很多學校還做不到。如果還遇到大版本升級，或者有架構方面大的升級，還需要更長的停機時間。

• 提前一段時間通知使用者即將停機維護

• 在進入停機模式，Nginx接管所有流量，給使用者一個維護模式頁面

• 如果可以，應先在備用環境演練遷移時間，將所有時間壓縮到最低，比如資料庫可以使用binlog傳輸變化量就不需要整庫倒資料，檔案傳輸rsync傳輸變化量等等。

## 能不能從Web小版本升級

用過WordPress的人都體驗過從Web安裝，從Web自動升級，能否引入這種機制，不要再從SSH跑命令升級了，讓升級更傻瓜一點。當然，要做到這步，考慮需要更多，比如安全性問題，指令碼執行超時問題等等。

## VPN和堡壘機

> 我們維護的院校，60%是需要VPN的，30%是需要堡壘機的，光VPN軟體就幾十種。

>

> 當前維護一個學校，只能登入1個學校的VPN，比如我在維護廈門大學的時候，就無法同時部署清華大學、北京大學

這裡面存在2個誤解。

• 有責任的外包公司，如果看到學校的伺服器維護居然可以不用VPN，不用雙因素認證的堡壘機，應當不是竊喜而是告知學校，這樣子很不安全！

• 是可以同時撥號10個學校VPN並透過路由指定網段走哪個VPN閘道器的。

當然，這有學校的問題，90%以上的高校的VPN設定手冊可能都是一大堆圖文並茂告訴使用者如何一步步設定VPN，很多管理員不知道其實可以直接開啟PowerShell視窗（Windows8、Windows10以上）輸入以下命令一鍵配置，並且複製黏貼保證不會出錯：

```powershell

Add-VpnConnection -Name "XmuIKEv2" 

-ServerAddress "mask.xmu.edu.cn" 

-TunnelType "IKEv2" 

-EncryptionLevel "Optional" 

-AuthenticationMethod Eap 

-RememberCredential

```

注意後面一定不要有-PassThru，寧願再跑一次Get-VpnConection，否則會汙染rasphone.pbk檔案。

針對以上外包公司來說，他只要加引數 -SplitTunneling $True 取消預設閘道器，然後就可以透過 Add-VpnConnectionRoute 。這個方案比route -p ADD好的地方在於，不會永久破壞你的路由表，只會在撥號VPN後生效。或者你也可以每次撥號VPN後手動route ADD。

檢視你加了多少路由沒有Get-VpnConnectionRoute命令，透過以下檢視：

```powershell

$conn = Get-VpnConnection -Name "XmuIKEv2"

$conn.routes

```

## SaaS、Semi-SaaS、On-Premises

如果能打包成容器部署更好，當然容器也在不停演進，安全性不是太樂觀，核心漏洞和容器漏洞都會導致容器逃逸。最新的有安全容器，在容器外面再套一層輕量級的虛擬化都是可以研究的。

因為交付很麻煩，有些外包公司直接給你提供SaaS服務。也有提供半SaaS服務，你多給點錢，他幫你在雲平臺開虛擬機器部署，甚至還可以給你機器密碼，純的SaaS你是拿不到資料庫許可權，半SaaS可能可以拿到。但是這裡就要注意到安全問題，半SaaS服務為了方便，他們可能直接SSH埠直接對外全部開放，不走堡壘機等等問題。

## 多臺Web

Web不是說想擴就擴的，Web要變多臺，你必須處理幾臺Web共享資料和狀態問題。而且Web擴完後日志也不是集中的。多臺Web升級程式碼也是比較麻煩的。這裡一般採用滾動升級或者使用負載均衡引流灰度升級。比如我部署的一個應用，前端一臺Nginx，後端10臺Web，我單獨劃出一臺給我自己線上除錯查錯，就簡單透過Nginx判斷remote_addr是我的IP，直接引流到某臺Web。

整個應用對外也應當對CDN友好，最近上了CDN我才發現，CDN針對動態網頁、靜態資源、流媒體點播、雲端儲存等不同快取的價格是不同的，所以有能力應當使用多個域名隔離這些資源，使得對CDN友好，節省學校的頻寬成本。

## 共享Session

程式語言一般都可以設定Session儲存到一個集中的資料庫，比如關係型資料庫，甚至記憶體資料庫。當然，你如果保證可以ip_hash到同一臺Web，Session可以直接放在Web，但是這個不夠健壯。如果Web當了一臺，Session會丟失。

## 共享Cache

一些全域性的Cache也可以考慮類似Session來處理。

## Cache

必須大量採用Cache。頁面必須解構，動態內容和靜態內容分開，快取時間不同的分開，JavaScript、Image全部版本化，輸出Cache-Control。我最近在安裝Moodle，Moodle這方面做得非常完美。

## 共享儲存

NFS已經進化到v4了，但是因為有網路參與，速度還是不容樂觀，考慮使用者傳一個1G的檔案到NFS，他需要先經過CDN->Nginx->Web->NFS，至少Web和NFS會有兩次落盤讀寫，時間會被延長20%。所以這個需要權衡。當然，如果有非同步機制，這個時間可以省下來，後端多臺Web再和NFS進行rsync同步。或者直接上分散式檔案儲存，雲端儲存，並且跟CDN做好對接，應當可以快取有許可權判斷的檔案。

## 資料庫

不要一上來就拿Oracle，是否可以採用MySQL，分庫分表？讀寫分離？

## 版本化

版本化一切，包括原始碼和資料庫。如果用過開源軟體，或者類似Django的Database Migrate機制就會很清楚。資料庫有自己的版本，一個版本字串寫在表結構內。Web來訪問必須匹配版本號，否則無法執行，提示升級。這樣子可以防止，假如你有10臺Web，但是運維沒睡好，只升級了其中9臺，漏了一臺，也不會影響資料庫的安全。這10%的使用者就會收到一個提示，也可以更快發現錯誤。如果你可以把學校程式碼也寫入原始碼和資料庫，就不會出現清華大學的程式碼誤傳到廈門大學並跑起來了。

> 定製呢？改首頁呢？

這個我們也遇到過，明明一個錯誤已經修正了，怎麼又跑出來？原來是運維升級錯版本了，覆蓋客製化內容了。升級好了，首頁怎麼亂了？客製化忘記修正了。所以這裡一定要做好各個不同學校的內容的隔離，使用配置檔案。git flow要認認真真去學習，如何做個主master倉庫，如何develop，hotfix，feature，release，不同學校的release版本。

當然對於學校來說，儘量減少定製，即使要定製，也要爭取定製內容進入公司產品主倉庫。定製是惡魔。

## 壓力測試

一般公司會說我們在哪個學校試過壓力測試，可以達到多少併發等等。但是這個不準，各個學校硬體環境和資料庫內容差異很大，沒有可比性，如果可以的話，儘量應當在本地直接壓力測試。

因為壓力測試錄製指令碼很麻煩，還需要處理登入問題，如果可能，應當有專門的程式碼，直接從資料庫生成JMeter指令碼，對登入做Hack，直接透過某種機制繞過登入，在跟生產環境基本一致的伺服器上做壓力測試。也就是，壓力測試也是要自動化，想要跑就可以跑的。

## 監控和日誌

在我以前說過，如果請外包公司做運維，應當將監控和日誌向運維公司開放。因為你一旦將Web擴充到多臺以後，查詢Log是非常麻煩的，你很難知道自己被ip_hash到哪臺Web了，所以必須中心化日誌。並且要定期檢視500錯誤，不要等使用者來報。

很多外包公司認為這個是學校的事情，確實，監控和日誌是安全合規的事情，學校一般也會已經建立，但是是否可以分許可權給你檢視這個得看學校買的日誌集中化產品的支援，甚至得看你能否進入學校安全核心網段。所以如果有能力，應當自己採用開源軟體也建立一套簡單的日誌採集工具，只給自己定位錯誤使用。

## 備份

備份友好也要考慮。比如你將檔案都寫入資料庫很省心，會造成資料庫很大，很難備份。或者檔案寫的路徑儘量按上傳時間分離而不是某個奇怪的hash演算法。當然備份學校也會有一套自己的規則，可以不用考慮太多。知悉學校的備份策略，也為自己運維人員操作留下後路。