本文結(jié)構(gòu)

前言

卓越操作定義

卓越操作支柱是AWS架構(gòu)完善框架的五大支柱之一，側(cè)重于運(yùn)行和監(jiān)測(cè)系統(tǒng)以提供業(yè)務(wù)價(jià)值，并不斷改進(jìn)流程和程序。關(guān)鍵主題包括：管理和自動(dòng)化變更、響應(yīng)事件以及定義標(biāo)準(zhǔn)以成功管理日常操作。

這份白皮書(shū)闡述了AWS架構(gòu)完善框架五大支柱中的卓越操作支柱，它討論了操作籌備、操作實(shí)施、操作演進(jìn)三個(gè)方面的概念、設(shè)計(jì)原則和最佳實(shí)踐，指導(dǎo)架構(gòu)師、軟件開(kāi)發(fā)人員在基于AWS平臺(tái)設(shè)計(jì)、交付和維護(hù)軟件時(shí)應(yīng)用這些最佳實(shí)踐。

下面的內(nèi)容是我閱讀AWS架構(gòu)完善卓越操作白皮書(shū)時(shí)整理的筆記和心得。

卓越操作設(shè)計(jì)原則

• 使用代碼進(jìn)行操作
  應(yīng)用基礎(chǔ)設(shè)施即代碼、使用代碼進(jìn)行變更、使用代碼響應(yīng)事件，減少人為操作失誤導(dǎo)致的失敗，快速響應(yīng)事件。
• 為文檔做注釋
  手工創(chuàng)建文檔時(shí)自動(dòng)生成注釋、每次構(gòu)建時(shí)自動(dòng)生成注釋文檔，注釋文檔能夠被人或系統(tǒng)使用（作為操作代碼的輸入），具體應(yīng)用場(chǎng)景？
• 進(jìn)行高頻、小型、可逆的變更
  代碼盡快入庫(kù)、入庫(kù)的代碼盡快上線生產(chǎn)環(huán)境，盡可能保證一次變更的變更內(nèi)容單一，從而提高變更成功率、縮短變更時(shí)長(zhǎng)、縮短變更失敗回退所需時(shí)長(zhǎng)。
• 持續(xù)改進(jìn)操作流程
  在操作過(guò)程中注意不足之處，尋找能夠改進(jìn)的地方，確定一個(gè)固定的時(shí)間對(duì)操作流程進(jìn)行回顧、討論、完善，確保團(tuán)隊(duì)熟悉這個(gè)過(guò)程。
• 預(yù)見(jiàn)錯(cuò)誤的發(fā)生
  即提前進(jìn)行故障場(chǎng)景梳理，分析影響，并制定必要的應(yīng)急響應(yīng)預(yù)案，確定一個(gè)固定的時(shí)間（“競(jìng)賽日活動(dòng)”）進(jìn)行運(yùn)維演練，檢驗(yàn)響應(yīng)預(yù)案的有效性以及團(tuán)隊(duì)是否具足夠的故障響應(yīng)能力。
• 從所有操作失敗中學(xué)習(xí)
  從所有操作事件和失敗中汲取經(jīng)驗(yàn)來(lái)推動(dòng)改進(jìn)，將經(jīng)驗(yàn)在團(tuán)隊(duì)內(nèi)部，以及整個(gè)組織范圍內(nèi)進(jìn)行分享。

籌備

確定優(yōu)先級(jí)

團(tuán)隊(duì)內(nèi)處理問(wèn)題時(shí)有必要對(duì)問(wèn)題優(yōu)先級(jí)進(jìn)行討論，建立共識(shí)。這樣能夠大大減少因認(rèn)識(shí)不統(tǒng)一，目標(biāo)不統(tǒng)一導(dǎo)致的團(tuán)隊(duì)內(nèi)沖突。

舉個(gè)例子，實(shí)現(xiàn)運(yùn)維需求時(shí)，需要根據(jù)業(yè)務(wù)要求對(duì)需求進(jìn)行排序，如果我們把運(yùn)維的需求劃分為兩大類：

• 第一類：對(duì)系統(tǒng)發(fā)布速度有提升的需求
• 第二類：對(duì)系統(tǒng)可靠性有提升的需求

如果客戶希望能夠快速看到運(yùn)行起來(lái)的系統(tǒng)原型，對(duì)于可靠性要求暫時(shí)不高時(shí)，那么可以適當(dāng)?shù)匕训谝活愡\(yùn)維需求的優(yōu)先級(jí)提高，以快速迭代交付新的演示功能；反之，若是在服務(wù)已公測(cè)或商用，使用者數(shù)目較大時(shí)，則需要優(yōu)先實(shí)現(xiàn)第二類運(yùn)維需求，提高系統(tǒng)可靠性，確保SLA達(dá)成。

再舉個(gè)例子，當(dāng)on-call接收到現(xiàn)網(wǎng)事件時(shí)，對(duì)于用戶報(bào)障類的問(wèn)題，應(yīng)該優(yōu)先考慮恢復(fù)，而后再進(jìn)行定位問(wèn)題。如果是開(kāi)發(fā)兼任on-call，而不是訓(xùn)練有素的專業(yè)on-call，很可能會(huì)習(xí)慣性地花費(fèi)大量時(shí)間定位根因。這樣客戶可能會(huì)不滿意，客戶迫切想要的可能是快速規(guī)避問(wèn)題，恢復(fù)業(yè)務(wù)，減少損失，降低名譽(yù)傷害。

設(shè)計(jì)時(shí)考慮操作

AWS建議在設(shè)計(jì)工作負(fù)載時(shí)，就考慮把部署、變更、監(jiān)控，告警納入考慮。這些領(lǐng)域主要包括：基礎(chǔ)設(shè)施即代碼，持續(xù)集成與持續(xù)部署，監(jiān)控，告警，分布式追蹤等。

相關(guān)的AWS服務(wù)：AWS CloudFormation，AWS Developer Tools（AWS CodeCommit、AWS CodeBuild, AWS CodePipeline，AWS CodeDeploy, and AWS CodeStar），AWS CloudWatch，AWS X-Ray…

有經(jīng)驗(yàn)豐富的SRE或是擅長(zhǎng)CICD工程師在服務(wù)孵化的早期就參與進(jìn)來(lái)，對(duì)于服務(wù)卓越操作目標(biāo)的達(dá)成將非常有幫助。

準(zhǔn)備度評(píng)估

閱讀過(guò)《Google SRE運(yùn)維解密》這本書(shū)的同學(xué)，看到這個(gè)小標(biāo)題時(shí)一定聯(lián)想到到了書(shū)中提出的PRR模型吧！PRR（Pilot Readiness Review，試點(diǎn)準(zhǔn)備度評(píng)估）模型是Google提出的用于評(píng)估一個(gè)系統(tǒng)的運(yùn)維能力是否滿足上線生產(chǎn)環(huán)境的要求的模型。

回顧一下，這個(gè)模型都講了些什么呢？其實(shí)就是一份Checklist，比如：服務(wù)的架構(gòu)設(shè)計(jì)是否滿足規(guī)范、基礎(chǔ)組件的選型是否使用公司內(nèi)部基礎(chǔ)設(shè)施工程部提供的標(biāo)準(zhǔn)的公共組件、可靠性（系統(tǒng)可靠性，數(shù)據(jù)可靠性，運(yùn)維可靠性，可靠性管理）是否滿足要求、可運(yùn)維能力（監(jiān)控，告警，日志采集，調(diào)用鏈能力是否具備）、基于業(yè)務(wù)場(chǎng)景的故障梳理，進(jìn)行運(yùn)維演練，測(cè)試故障處理流程，應(yīng)急響應(yīng)預(yù)案是否有效…

不在這個(gè)模型里的一點(diǎn)應(yīng)該是對(duì)處理事件的人員進(jìn)行培訓(xùn)，確保他們具備足夠的知識(shí)和技能。

相關(guān)的AWS服務(wù)：AWS Config（配置基線話，如果更改了配置導(dǎo)致系統(tǒng)故障，能夠快速回退到上一份正確的配置，快速恢復(fù)環(huán)境），AWS System Manager

操作

理解操作健康

一次成功的操作代表新的配置生效了，或者新的特性上線了，并且原有的和新增的撥測(cè)用例都還能執(zhí)行成功。AWS建議通過(guò)定義明確的業(yè)務(wù)和技術(shù)指標(biāo)，并把它們呈現(xiàn)在看板上，以便在操作失敗時(shí)快速得到反饋，并及時(shí)作出響應(yīng)。

相關(guān)的AWS服務(wù)：Cloud Watch Log/Event，Personal Health Dashboard，Service Health Dashboard，AWS Elastic Search。

響應(yīng)事件

這部分談?wù)摰氖鞘录芾碣M(fèi)流程。事件分類，預(yù)料的和未預(yù)料的。處理事件需要依據(jù)一個(gè)不斷完善的事件處理流程。這個(gè)流程需要保證事件的處理進(jìn)展和問(wèn)題影響能夠及時(shí)地同步到關(guān)心事件的相關(guān)團(tuán)隊(duì)，處理阻塞時(shí)要分層上升，以便請(qǐng)求更強(qiáng)的資源幫助問(wèn)題解決！問(wèn)題解決要追求根因分析，從源頭上解決問(wèn)題，避免再次出現(xiàn)相同的問(wèn)題。

相關(guān)的AWS服務(wù)：AWS提供了一些服務(wù)能夠監(jiān)控某些事件的發(fā)生（Cloud Watch），配置規(guī)則（Cloud Watch Rules），觸發(fā)目標(biāo)服務(wù)（Cloud Watch Target）執(zhí)行預(yù)定義的操作（Cloud Watch Event）作為響應(yīng)，比如：發(fā)送短訊通知（SNS），執(zhí)行Lambda函數(shù)（AWS Lambda），執(zhí)行EC2實(shí)例任務(wù)，自動(dòng)伸縮動(dòng)作（Auto Scaling）

另外，AWS也對(duì)一些第三方的監(jiān)控，數(shù)據(jù)處理軟件提供了支持，能夠把數(shù)據(jù)通過(guò)API發(fā)送給第三方應(yīng)用。

演進(jìn)

通過(guò)經(jīng)驗(yàn)學(xué)習(xí)

定期分析失敗用例，并從中學(xué)習(xí)，避免團(tuán)隊(duì)，或者所處的更大的項(xiàng)目組避免重蹈覆轍，這是非常有意義的。

AWS能夠幫助聚合操作活動(dòng)，工作負(fù)載，或者基礎(chǔ)設(shè)施的日志（CLOUD WATCH），并提供相關(guān)的工具幫助分析我們的操作，趨勢(shì)或者不同系統(tǒng)在不同配置下對(duì)操作的響應(yīng)結(jié)果，基于此，我們能夠分析計(jì)劃改進(jìn)。

相關(guān)的AWS服務(wù)：Amazon QuickSight，Amazon Athena，Amazon S3，Amazon CloudWatch

分享學(xué)習(xí)收獲

在團(tuán)隊(duì)內(nèi)、不同團(tuán)隊(duì)間、組織內(nèi)分享文檔，標(biāo)準(zhǔn)的基礎(chǔ)設(shè)施模板，有需要時(shí)可對(duì)分享的資源設(shè)置必要的訪問(wèn)權(quán)限。

相關(guān)的AWS服務(wù)：AWS Identity and Access Management，Amazon SNS，AWS CodeCommit，AWS Lambda，AWS CloudFormation，Amazon Machine Images（AMI）

總結(jié)

以上籌備、操作、與演進(jìn)三部分內(nèi)容可總結(jié)提煉出以下卓越操作最佳實(shí)踐：

• 運(yùn)維人員需要理解業(yè)務(wù)和客戶需求才能有效、高效支撐業(yè)務(wù)
• 運(yùn)維人員創(chuàng)建操作流程并在實(shí)踐中檢驗(yàn)流程是否有效支持業(yè)務(wù)需要
• 運(yùn)維人員需要通過(guò)制定、采集指標(biāo)來(lái)衡量目標(biāo)達(dá)成情況
• 業(yè)務(wù)場(chǎng)景、業(yè)務(wù)優(yōu)先級(jí)、客戶需求會(huì)不斷發(fā)生變化，在變化來(lái)臨是，需要能夠及時(shí)調(diào)整操作流程以適應(yīng)改變

心得感想

從持續(xù)改進(jìn)操作流程到當(dāng)責(zé)文化
確保團(tuán)隊(duì)熟悉相關(guān)的重要流程很重要，但是制定符合實(shí)際、具備可操作型的流程更重要，制定安排工作計(jì)劃時(shí)也是。如果流程規(guī)范/工作安排不是切實(shí)可行的，團(tuán)隊(duì)成員默默接受遵循/進(jìn)行不切實(shí)際的流程規(guī)范/工作的要求，放棄主動(dòng)思考流程規(guī)范中存在的問(wèn)題、工作的實(shí)際內(nèi)容合理的工時(shí)并提出自己的看法，可以預(yù)見(jiàn)的是團(tuán)隊(duì)成員將無(wú)法遵循規(guī)范或按時(shí)完成工作，這對(duì)團(tuán)隊(duì)內(nèi)當(dāng)責(zé)文化的建立非常不利。

AWS卓越操作支柱與Google SRE
AWS卓越操作支柱中的設(shè)計(jì)原則和最佳實(shí)踐與Google提出的SRE指導(dǎo)思想和最佳實(shí)踐具有相似性：

參考鏈接

• https://d1.awsstatic-china.com/whitepapers/architecture/AWS-Operational-Excellence-Pillar.pdf
• https://amazonaws-china.com/cn/architecture/well-architected/
• https://amazonaws-china.com/cn/blogs/apn/the-5-pillars-of-the-aws-well-architected-framework/q