SRE本読み返して１

こんにちは、季節はもう秋ですね。急に気温が下がって体調不良には気をつけたいです。 データベース設計のことをブログとしてまとめていましたが、僕自身SREエンジニアなので、原点に立ち帰って(というか経験はかなり浅い)SRE本を再度少しづつ読んで自分用にまとめていきたいと思います。

第一章

元来企業にはシスアド(Ops)が存在しており、基本的なサーバーの運用業務などはシスアドが行なっていた。 従来型の企業では開発者と運用担当者で線引きが(ガードレールが引かれていた)行われていた。 開発者はビジネスサイクルを回すために、機能を開発をして変更をリリースしたいが、運用担当者はリリースによる不具合のリスクを下げたい(システムの安定化)を行いたい。こいったことからDev vs Opsの構図が出来上がってしまった。 SREとは運用の側面をソフトウェアの力で負荷を軽減することを目指し定量的判断をもとそのサービスの信頼性を向上めざす言わばプラクティス、動機付けである。

第三章

第二章はgoogleのシステムアーキテクトな話さのでスキップ。 リスクの受容という項目。サービスの100%の信頼性を提供するのは難しいし、現実的ではない。 どんなに優れたサービスアーキテクトで素晴らしいパフォーマンスでも、それ以前のネットワークレイヤーでパケロスをするかもしれないから100%のサービス稼働(信頼性)を行うことは不可能に近い。 それにシステムに100%の稼働といった信頼性を追い求めると、金銭的コストが増大する。 userにとってはネットワークレイヤーの不具合、提供するサービスでの不具合の原因内容の関心ごとは持っていない。それらはuserにとっては包括的にサービスの信頼性と考える。その為100%の信頼性の提供は現実ではない。 また100%の信頼性を追うことに集中すると新機能開発のなどのチャンスを失う可能性がある。よって信頼性とリスク許容はトレードoffなのだ。 信頼性の指標はどうやって表すのか、それはサービスの特性とuserが中心でなくてはならない。 サービスの特性、userが求めるものを加味した上で可用性やレイテンシに関する指標を作成する。 指標の定義は一旦は割愛する。 忘れてはいけないのはその指標を観察するにはuserやサービス特性を忘れてはいけない。なぜなら、userとしてはシステムのcpu使用率やメモリーの消費率は気にしていないというか関心ごとではないからだ。 第三章には明確には話が出てはないが、サービスの指標をSLI(service level indicator)という。そこから目標値(SLO)を定義し、現実のギャップをエラーバジェットとして管理し、信頼性向上の取り組み(パフォーマンス改善)や継続的リリースを推し進めていく。

終わりに

まだまだ続く。。