混合雲發生事故時、誰應付上責任？管理員又應如何制定 SLA？
混合雲 (Hybrid Cloud)，固名思義就是將私有雲、公有雲結合而成；身為 IT 人亦明白到當混合之中的一部份，例如是公有雲出現問題時(公有雲如 AWS、Azure 又或者像 Google Cloud 等)，責任理應屬於這些公有雲端服務供應商；然而作為使用者，他們並不需要知道你正在使用甚麼「雲」，他們只關心當事故出現時，何時才能修復；所以身為 IT 人亦唯有替公有雲服務供應商「食死貓 (背黑鍋)」，因此作為一個盡責的管理員，在部署混合雲這類架構前，要如何就混合雲制定適當的 SLA (Service-Level Agreement) 便顯得十分重要。
多想想你可能會為自己制定的 SLA 而睡不著……
要在混合雲之中制定 SLA，其實並非全無可能，最主要是管理者需了解混合雲之中不同部份的責任歸那方，同時更需了解不同等級的公有雲服務，其本身提供的 SLA 條款。舉個例子，假如你正使用 Amazon (AWS) 所提供的服務，那萬一 Amazon 的服務連線上出現問題，例如是出現緩慢時，你可能會認定這是屬於 Amazon 責任，對吧？但問題是，別人總不會承認，反而會認為是貴公司的私有雲線路出現問題，因而導致緩慢情況；所以別以為混合雲的 SLA 很容易制定！其實多想想你可能會為自己制定的 SLA 而睡不著呢！！
不採用公有雲服務供應商至少可保平安……
面對上述情況，都是老生常談的解決方法，那就是認清不同連線之間數據 進/出/傳輸 當中的責任，這點在制定 SLA 時，必須多想！儘管要求公有雲按你所想更改 SLA 似乎不太可能，只不過你卻可以藉此要求不採用公有雲服務供應商又或者轉換其他可接受你提出 SLA 要求的公司，那麼萬一出現問題時，責任至少不在你身上，亦免卻了為往後升職加薪留下了一個污點！
硬是要用，唯有注意 SLA 分界線……
萬一真的要使用指定的公有雲服務供應商，那麼在詳細查看她們提供的 SLA 時，其重點應放在 SLA 之中提及的分界點，這些分界點往往是指不同的應用層 (application stack) 內的 Layer，每個公有雲的 SLA 很常都會以此區分從那裡到這裡的責任誰屬，有些會針對 OS、Container 又或者其中一層 Layer 作為起點或終點，通過了解當中細節，冷靜想想後，你便會較容易清楚這些公有雲的 SLA 所覆蓋的範圍，包括由 A 點開始到 B 點完結，當中所有責任是由公有雲供應商負責，那麼你便會輕易的制定到私有雲的 SLA，更甚者亦可參照公有雲的方法，以不同的應用層 (application stack) 內的 Layer作為標準去制定私有雲的 SLA，如此一來便可較容易達成共識。其實說白一點就是公有雲不會為你改變，但你卻可為公有雲改變 SLA….. 🙁
終極方法 – 公司 SLA 較寬鬆賺回公有雲 SLA 的嚴僅……
其實還有一個方法，這是筆者多年來的經驗，就是為自己公司內部使用的 SLA 爭取更寬鬆的條件，事關這點你可以控制，因此可制定較寬鬆的 SLA 以應對公有雲萬一出現問題時的特殊情況，至少可讓自己較能安心睡個好覺、發個好夢。
