Developers Summit 2018 「もしSIerのエンジニアがSRE本を読んだら」を聞きました

Tweet

以下は、思ったことや気になったことをメモしていますので、必ずしも登壇者の発表内容やご意見ではないことを、ご承知おきください。

スピーカーはエーピーコミュニケーションズの安藤さん

システム運用の理想と現実

運用の現場では絶対的な力関係が決まっていて、非効率な場面もあり、終りも先も見えない、という課題(暗い話)がある。
運用を自動化して、心理的安全性を確保する、そうすることで合理的で高い生産性を求める。
でも現実は低い生産性でやらされ感、受け身で暗くなる。

我々が解釈したSRE(サイトリアライビリティエンジニアリング)

そこでSRE。

大規模サービスにおける運用ベストプラクティス。

リスクを受容して信頼性100%は目指さない。
SLI(サービスレベルの指標)をもとにSLO(サービスレベルの目標)を決める。
人による判断→データによる判断で標準化する。
現実ではお客様ありきなのでSLAに偏りがちで100%を求められがち。

トイル

手作業で繰り返し行われる自動化可能な作業、サービスが成長すれば増える。なのでこれを撲滅する。
自動化するための技術力不足。

自分たちなりのSREの実践

50%ルール

現実は運用業務が100%+のところが多い、が、トイルを撲滅することにより50%を目指したいがトイルを撲滅するための時間確保が出来ない。
なので、タスク整理、棚卸し、優先順位をつけて要らないタスクを捨てる。
捨てられないものはお金の力で解決するのもあり。自分たちがやるべきなのか、他社にやってもらったほうがいいのか、サービスによって解消できないか、を検討した。
タスク順序を入れ替えることで待ち時間、オーバーヘッドを減らせることもある。
イレギュラー手順を排除する。後々に自動化する場合でも、共通手順の方が自動化しやすい。

自動化するまでに整理、捨てる、順序、共通化しておけば、自動化する際に効率的に出来る。なるほど。 #devsumiB

— やました (@yamamanx) 2018年2月16日

「変わらないリスク」は端的に言うと「衰退」かと思います。安全かもしれないけど発展しないので他のサービスに超えていかれるので向かう先は「衰退」しかないのではないかと思います。 #devsumiB

— やました (@yamamanx) 2018年2月16日

SREまだ読んでないけど、大枠ではこういうことなのか。読もう。 #devsumiB

— やました (@yamamanx) 2018年2月16日

自動化が少しでも出来ればそれで空いた時間でさらなる自動化が出来るはず。なので少しでもいいから踏み出す。そのためにはなるべく簡単に出来るように新しい技術を身に着けておく。 #devsumiB

— やました (@yamamanx) 2018年2月16日

最後までお読みいただきましてありがとうございました！

【PR】 「AWS認定試験対策 AWS クラウドプラクティショナー」という本を書きました。

【PR】 「AWSではじめるLinux入門ガイド」という本を書きました。

【PR】 「ポケットスタディ AWS認定 デベロッパーアソシエイト」という本を書きました。

【PR】 「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。