Help us understand the problem. What is going on with this article?

元Cybozu萩原さんからSREについて僕が学んだこと(基礎編)

More than 1 year has passed since last update.

こんにちは。@katsuhisa__ です。

本記事は、「SRE Advent Calendar 2017 」の12/2(土)分です。

また、本日「Cybozu Tech Conference 2017」にて私がLT する内容を記事として書き起こしたものです。LT 資料はこちらにおいてありますので、もしよければ併せてご参照ください。

(前置き)萩原さんとは

元 Cybozu インフラチーム副部長
現 levii CTO 兼、弊社スタディスト技術顧問

弊社スタディストの技術顧問に就任していただいた際のプレスリリースはこちら

萩原さんからSRE について学んだこと

  • 自動化しなくてもToil は減らせる
  • モニタリングとアラートを正しく活用
  • SLI を策定し、サービス状態を正しく把握せよ

順を追って見ていきます

自動化しなくてもToil は減らせる

萩原さんが弊社スタディストの技術顧問に就任してから、現状のインフラ関連の運用業務の棚卸しを行いました。
その過程で、定常的に行っているインフラ業務(Toil )のうち、いくつかはかんたんな施策を行うことにより、実施頻度を減らせそうだ、ということが分かりました。

Toil を減らす、というと真っ先に自動化を思い浮かべるかと思いますが、コードの実装にもそれなりに時間がかかりますよね。(もちろん実装コストの低いものに関しては、すぐ自動化するように心がけています。)
当時、私はすべてを自動化で対応しないといけないと思い込んでいたこともあり、「いまは別の優先度高い開発案件もあるし、Toil 削減のための自動化はもうちょっと後回しにしよう」と思っていました。

しかし、実際に萩原さんのアドバイスに従い、定常作業の頻度を減らす施策を行ったところ、私の業務負荷は大幅に削減されました。至極当たり前のことに見えますが、がんばって自動化しなくても、単にToil を減らせば運用は楽になるのですね。

Google のSRE 本でも、「Toil を減らせ」ということが書かれていますが、よく読んでみると、「業務の50%以上をToil に費やすな」ということが書かれていますよね。
つまり彼らの業務にもToil は残っており、それを優先順位をつけながら自動化を進めているのだと思います。(実際に中の人に話を伺ってみたいものです。)

近年、2回以上実施するタスクは、なんでもかんでも自動化することが常に正義という風潮があり、私もそう思い込んでいたのですが、この件は私にとってまさにコロンブスの卵のような話でした。

もちろん優秀なSRE がたくさんいて、毎日SRE 本来の活動に集中できる素晴らしい環境であれば、それは素晴らしいことであり、自動化を否定する気は1ミリもありません。
ただ、リソースの限られたスタートアップでの生存戦略の1つとして、この発想の仕方自体が非常に応用の効く素晴らしいものだと思います。
もし参考になったよーという方がいれば、みなさんの会社でも似たような取り組みを是非行ってみて下さい。きっと効果が出るはずです。

モニタリングとアラートを正しく活用

弊社では、以前、適切な監視システムが整備されておらず、障害時の影響や原因の切り分けがかなり高コストになっていました。
また、アラートも適切に設定されているとはいい難い状況で、アラートを起点にして調査を行ったが、単なる一時的なサーバー負荷上昇のみで、顧客影響はまったくなかった、なんてこともよくありました。

そこで、萩原さんと相談した結果、

  • 不要なアラートの抹殺
  • 新規監視システムの導入

の2つの施策に取り組みました。

これらも、先ほどのToil 削減の施策に引き続き、施策完了後の効果は絶大でした。
不要なアラートがこないことで、私の精神的な負荷が現象し、そして無駄な調査を実施する必要もなくなりました。

さらに新規監視システムの導入を行ったことで、これまで見えなかった傾向もつかみやすくなり、性能改善関連の施策が非常に回しやすい状態になりました。

SLI を策定し、サービス状態を正しく把握せよ

最後にSLI の話です。

「なんかいま遅い気がするけど大丈夫?」となった際に、状況がうまく把握できず、「うーん、これは他のお客さんの環境では大丈夫なのか?」と困ってしまったことはありませんか?
例えば、社内のネットワーク環境側に問題があったとすると、システム側の状況をいくら調査しても、知りたい答えにはたどり着けません。

これまで弊社では、SLA は設定していたものの、ふだんのインフラ運用時に気にかける指標や、問題を具体的に定義するための判断指標がありませんでした。そのため、上述したような状況の場合、とりあえずいろんな監視システムで取得している指標を個別に確認し、その結果ようやく「調査しましたが、おそらく大丈夫です」といった判断をしていました。

そこで、萩原さんと改めてSLI について議論し、また、SLI を判断するために監視システム(前述した監視システムと同一)を活用するようにしました。
その結果、サービスの状態を正しく把握することができるようになりました。そのおかげで、前述したような、実は社内ネットワークが遅いだけなのにシステムの調査をがんばる、みたいな誰も幸せにならない無駄な仕事から開放されました。

まとめ

SRE という仕事に就く人たちは、今はどこの会社でもめちゃくちゃ人手が足りていないように思います。(私の肌感覚ですが・・・)
ですので、いまご自身の持ち場でがんばっている皆さんには、できるだけSRE 本来の仕事に取り組むべく、無駄な運用業務は減らすことが重要であると感じます。そのために、本記事がお役に立てば幸いです。

というわけで、他の「SRE Advent Calendar 2017 」の記事もたいへん楽しみにしています。お読みいただきありがとうございました。

@katsuhisa__

katsuhisa__
B2B SaaSのスタートアップでSRE をやっています。
https://speakerdeck.com/katsuhisa91
studist
「伝えることを、もっと簡単に」をミッションにビジュアルSOPマネジメントプラットフォームのBtoB SaaS「Teachme Biz」を開発・運営するスタートアップ
https://medium.com/studist-dev
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away