在創(chuàng)業(yè)的世界里，當(dāng)你把時(shí)間投入到哪里時(shí)，有一個(gè)平衡的行為。我遇到過很多情況，由于需要發(fā)布 MVP，DevOps 實(shí)踐處于次要地位。

我認(rèn)為這是正常的，并不是一件壞事，因?yàn)椤癕VP”應(yīng)該是“最小的”，而好的 DevOps 解決的大多數(shù)問題都不是這么小的問題。

但這里有幾件事絕對(duì)應(yīng)該做（或至少考慮）。因?yàn)樵趧?chuàng)業(yè)世界中，沒有比讓您的云基礎(chǔ)設(shè)施崩潰更糟糕的事情了。

提示 #1：安排數(shù)據(jù)備份？

對(duì)于任何關(guān)心擁有持久數(shù)據(jù)的初創(chuàng)公司來(lái)說(shuō)，這都是必須的。您需要自動(dòng)備份您的關(guān)鍵數(shù)據(jù)，否則您可能不僅會(huì)丟失文件，還會(huì)失去客戶信任，這將影響您未來(lái)的發(fā)展。

我通常在啟動(dòng)項(xiàng)目時(shí)自動(dòng)執(zhí)行兩種類型的備份方法

數(shù)據(jù)庫(kù)備份

這通常采用計(jì)劃腳本的形式，例如每天晚上運(yùn)行的 cron 作業(yè)，并將數(shù)據(jù)庫(kù)轉(zhuǎn)儲(chǔ)推送到云上某處，例如私有 S3 存儲(chǔ)桶。您可以通過一些備份解決方案獲得更多奇特的解決方案，但這些解決方案往往更側(cè)重于企業(yè)，并且會(huì)花費(fèi)您大量的時(shí)間和金錢（對(duì)啟動(dòng)不友好）。

磁盤快照

當(dāng)所有其他方法都失敗時(shí)，如果您有磁盤副本，通常會(huì)很安全。大多數(shù)主要的云提供商都有適當(dāng)?shù)慕鉀Q方案，可以讓您按照您選擇的時(shí)間表拍攝磁盤快照，因此請(qǐng)盡量避免編寫直接連接到云 API 的腳本，因?yàn)槟鷮⒇?fù)責(zé)維護(hù)它們。

??？確保測(cè)試您的備份恢復(fù)方法或風(fēng)險(xiǎn)發(fā)生在 GitLab上，他們的所有 5 種備份方法都失敗了，因?yàn)樗麄儚奈礈y(cè)試過恢復(fù)？

提示 #2：設(shè)置監(jiān)控并收到問題警報(bào) ??

您會(huì)知道服務(wù)器何時(shí)出現(xiàn)故障或應(yīng)用程序因磁盤空間不足而崩潰嗎？如果沒有，您應(yīng)該考慮解決該問題（不需要太多時(shí)間）。

設(shè)置監(jiān)控的最簡(jiǎn)單方法通常是像Amazon CloudWatch或GCP?Stackdriver 這樣的云提供商解決方案。您可以設(shè)置指標(biāo)來(lái)監(jiān)控和發(fā)出不同類型的警報(bào)，以響應(yīng)云基礎(chǔ)架構(gòu)中發(fā)生的這些事件，例如當(dāng)您的磁盤運(yùn)行不足時(shí)收到一封電子郵件。

如果您不想使用供應(yīng)商的解決方案——也有與云無(wú)關(guān)的選項(xiàng)可以監(jiān)控您的云。存在簡(jiǎn)單的解決方案，例如安排定期運(yùn)行發(fā)送電子郵件的 shell 腳本，但更全面的解決方案為您提供系統(tǒng)的儀表板視圖通常更好且更具可擴(kuò)展性。企業(yè)私有云存在Blue Medora和Solar Winds等選項(xiàng)，但大多數(shù)初創(chuàng)公司需要省錢，這意味著轉(zhuǎn)向開源解決方案，例如Countly。

總而言之，我建議使用基于云提供商的解決方案，因?yàn)檫@些解決方案將保證穩(wěn)定、易于設(shè)置，并且在初創(chuàng)公司的規(guī)模上不會(huì)花費(fèi)你太多額外費(fèi)用。

提示 #3：轉(zhuǎn)向 CI/CD 管道？

我在初創(chuàng)公司中看到的常見難題之一是發(fā)布代碼的過程。許多人還沒有將時(shí)間投入到 DevOps 來(lái)開發(fā)穩(wěn)定的發(fā)布管道，這意味著推送到版本控制的代碼要么是手動(dòng)測(cè)試、構(gòu)建和發(fā)布，要么容易出錯(cuò)，而且對(duì)你的開發(fā)來(lái)說(shuō)很耗時(shí)團(tuán)隊(duì)。

持續(xù)集成——確保變更不會(huì)中斷

持續(xù)集成的重點(diǎn)是每次代碼準(zhǔn)備好提交時(shí)都會(huì)啟動(dòng)一個(gè)管道。

1. 代碼提交到版本控制
2. 像 Jenkins 這樣的自動(dòng)化系統(tǒng)會(huì)創(chuàng)建應(yīng)用程序的構(gòu)建
3. 執(zhí)行自動(dòng)化測(cè)試以驗(yàn)證系統(tǒng)是否仍然正常工作
4. 一旦所有測(cè)試都通過，就可以將代碼添加到穩(wěn)定的代碼庫(kù)中
5. 新代碼現(xiàn)在可以部署了（這就是持續(xù)部署發(fā)揮作用的地方）

持續(xù)部署——自動(dòng)化你的發(fā)布到生產(chǎn)

持續(xù)部署在您的持續(xù)集成管道完成驗(yàn)證新代碼的工作后開始，不會(huì)破壞您的構(gòu)建。這通常包括創(chuàng)建一個(gè)新的生產(chǎn)構(gòu)建，就像在持續(xù)集成階段所做的那樣，并替換舊的構(gòu)建（不可變的基礎(chǔ)設(shè)施）。

從技術(shù)上講，您可以在沒有持續(xù)集成的情況下進(jìn)行持續(xù)部署，但這樣做的風(fēng)險(xiǎn)很大。您基本上會(huì)將未經(jīng)測(cè)試的代碼直接推送給客戶（？B?AD？）

轉(zhuǎn)向 CI/CD 時(shí)應(yīng)該從哪里開始？— 自動(dòng)化測(cè)試！

眾所周知，大多數(shù)開發(fā)人員不喜歡編寫測(cè)試。隨著應(yīng)用程序的發(fā)展，它們往往需要不斷更新，并且需要大量時(shí)間，因此許多初創(chuàng)公司自然會(huì)因?yàn)椤癕VP”而忽視編寫測(cè)試。

如果您沒有全面的測(cè)試套件，我不會(huì)費(fèi)心考慮 CI/CD，直到解決此問題。隨著測(cè)試覆蓋率的提高，您將開始看到主要的效率提升，因?yàn)槟吹缴a(chǎn)中的錯(cuò)誤越來(lái)越少。這是您應(yīng)該繼續(xù)進(jìn)行 CI/CD 管道的其他部分的時(shí)候。

提示 #4：容器化您的應(yīng)用程序？

不要害怕容器，雖然技術(shù)本身很復(fù)雜，如果沒有內(nèi)核的基本知識(shí)就很難理解，但利用它們并將應(yīng)用程序轉(zhuǎn)換為容器真的很簡(jiǎn)單。

整理一個(gè) Dockerfile（取決于您的應(yīng)用程序的復(fù)雜性）通常需要不到一個(gè)小時(shí)的時(shí)間，并且在您知道它之前，您可以立即部署您的應(yīng)用程序并利用 Kubernetes 等出色的系統(tǒng)。

以下是通過容器化應(yīng)用程序可以立即獲得的一些好處。

一致的構(gòu)建

不再有“它在我的機(jī)器上工作”的問題——如果容器構(gòu)建，它將以相同的方式在任何機(jī)器上運(yùn)行。

無(wú)痛部署

你知道當(dāng)你想建立一個(gè)開源項(xiàng)目時(shí)，你必須經(jīng)歷各種手動(dòng)步驟，設(shè)置數(shù)據(jù)庫(kù)和安裝所需的包嗎？使用容器不再是這種情況，所有這些步驟都被納入構(gòu)建過程，您需要做的就是運(yùn)行一個(gè)命令來(lái)啟動(dòng)您的服務(wù)器。

充滿活力的容器生態(tài)系統(tǒng)

Docker 和 Kubernetes 等容器平臺(tái)擁有龐大且不斷增長(zhǎng)的產(chǎn)品和服務(wù)生態(tài)系統(tǒng)，可幫助您更輕松地管理應(yīng)用程序?；旧舷酥T如存儲(chǔ)、網(wǎng)絡(luò)和資源分配之類的許多令人頭疼的事情，從而節(jié)省了您的時(shí)間和金錢。

結(jié)論

許多初創(chuàng)公司并沒有在他們的云基礎(chǔ)設(shè)施上投入太多精力或時(shí)間。這通常是由于 MVP 的理念是先發(fā)貨，然后再清理技術(shù)債務(wù)。

在尋求擴(kuò)展您的 DevOps 基礎(chǔ)架構(gòu)時(shí)——考慮計(jì)劃備份、監(jiān)控、CI/CD 和容器化。這些通常很容易獲勝，并將導(dǎo)致更加穩(wěn)定的云。