🌱

何が運用負荷を増大させるのか?課題と解決、どういうチームになっていくべきか。

に公開

自己紹介

ログラスの勝丸(@shin1988)と言います。最近はクラウド基盤チームというチームのマネージャーをやっています。今回のLoglass Tech Blog Sprintは「運用負荷」について書いてみたいと思います。

背景

最近段々と運用負荷が高まっているな実感することが増えてきました。ログラスは2020年に本番ローンチをして、もう5年ほど運用を行っています。おかげさまでお客様が増えてきて、プロダクトも大きくなってきました。新規事業も色々始まってきており、開発チームも大きくなってきました。
いわば運用の視点の価値が相対的に高まってきているタイミングです。「どういう価値を作っていくのか?」と同時に「どうやって価値を感じ続けていただくのか?」という点にもフォーカスをしていきたい。そう考えるようになってきました。

またそのように視点を変えていくために、「何が運用を大変にするのか?」を考えてみたいと思い記事にしてみます。

何が運用の負荷を増大させるのか

何が運用の負荷を増大させるのか?その可能性を挙げてみます。

作りすぎている

当然のことですが、作ったものは運用が必要になります。更に新しいシステムを作った場合、またそのシステムの運用が必要になります。シンプルに作りすぎているから運用負荷が上がっているということがあります。作るものは減らせないでしょと思うかもしれませんが、そもそもそれが必要なのはなぜですか?だったり、今このタイミングでやる必要ありますか?もう少しタイミングを後にズラせないですか?などコミュニケーションで作る量を減らせる可能性があると思います。
トライ&エラーで挑戦は称賛されるべきことです。ただ、そのトライはちゃんと畳めてこそ良きトライとなるはずです。

システム特有の特殊事情が存在している

「例外」や「特殊事情」は足かせになると痛感しています。
特定のシステムや機能のために設けられた「例外ルール」が、運用負荷を異常に上げると感じています。

「このシステムだけは、ちょっと特別でね…」
「あそこの機能だけ、こっそり手動でやってて…」
こういうの聞いたことありませんか?

普段はAでやってるのに、たまにBが出てくるだけで、頭の切り替えとか、手順の確認とか手間が爆発的に増えます。またシステム全体の例外を減らすことは緊急時の対応にも活きるなと思っています。

緊急対応は事象への対応も重要ですが、対応に失敗すると二次被害を生みます。例外ルールが絡むと、原因特定にめちゃくちゃ時間がかかってしまったり、緊急対応が失敗する可能性を高めます。
なので、システム設計の段階から、「例外は極力作らない」という強い意志が大事だと思います。

運用を作りきれないままリリースしている

「リリースは間に合ったけど、一部は運用でカバーする」
エンジニアをやってると1度は言ったことがあると思います。運用や品質はリリース後に変更しようとすると手間が異常に上がります。
リリースだけをゴールにした「ツケ」は全部、運用する人への「手作業」に回ってきます。
まずはリリース優先で、一部の作業を手で行い後々に改善を行う予定が、そのまま手作業が残ったままになっているということはありませんか?いつまでに手作業が無くなっていないといけないのか?や、無くなっていない場合はどうするのか?をチーム内で相談できると良さそうです。

システム依存度の複雑性が上がっている

これもリリースから時間が立つと起こりがちかなと思います。シンプルだったものが時間が経つにつれて複雑になる問題はあるあるかなと思います。依存度の例であげると、データ連携の場所が増えたり、システムに変更を入れるための前提が必要だったり。

システムの依存関係はなかなか可視化されづらい側面があると思います。システム構成図などドキュメンテーションやオブザーバビリティを上げるツールを導入し、マッピングして可視化するなどすると良いと思います。

システムの知見をチームで共有できていない

自動化も大事だし、ドキュメンテーションも大事なんですが、やっぱり知見は人に宿ると思います。人に宿った知見をどうやってチームの共有知にしていくのか。
ここは時間がかかりますが、少しずつ広げていくしかないと思います。

どうすればいいのか

以上のような問題にどう対応していけばいいのでしょうか?正直この領域に銀の弾丸はないなと感じています。ここまで読んでいただいたのに申し訳ございません。ただ本当に一発で解決する方法はありません。ただこの辺から取り組めると良さそうというポイントはあります。

まずは運用しているシステムの棚卸しから

まずはシステムの棚卸しをしましょう。誰がオーナーになっているのか。チーム?個人?オーナー不在になっていない?など、今は使われているのかそうではないのかを明らかにしましょう。

作ったままで放置になっているシステムは大小あれど、どこにでもあると思います。放っておけば動き続ける壊れたときに直し方がわからないになりがちです。動いているうちに少しずつ改善しましょう。
また、作った当時の技術ではサポートしていなかったが、AWSなどのプラットフォーム側が対応しているケースがあったりします。できるだけ新しい技術で書き換えるは余力があればやったほうがいいです。

人をアサインしよう

運用を安定化させるためには人が必要です。「専任」の担当を置く、もしくは「運用に責任を持つ人」を明確にすることが運用には必要です。
日々の開発や新規事業に追われていると、どうしても運用って後回しになりがちです。

「手が空いた人がやる」「なんとなくできる人がやる」ってなりがちですが、それだと永遠に「運用がしんどい」ループから抜け出せません。

どれだけ早い段階で思い切って運用に集中できる「専任」の担当者やチームを設けることができるか。次に運用を「誰の仕事でもない状態から、みんなの仕事にすること」この状態になれば勝ちです。

AIが助けてくれる?

昨今のAIブームで、ドキュメント管理が楽になるのではという期待をしています。
弊社でもまだまだ模索している段階ですが、ドキュメントを書く、ドキュメントを探すという両軸において劇的に負を解消できるのでは?と思っています。
このシステムって何をしている?このシステムってどこと依存している?など探すことなくフランクに聞くことが出来るようになると思います。
ドキュメント管理の話はどこかで成果を発表できればと思います。

最後に

色々書いてきましたが、人と時間と覚悟を持って1歩目を踏み出すしか改善への道はないなと感じています。またシステム開発に悪意などはないなと常に思います。善意しかない。
その誰かの善意を無駄にしないために、適度にふりかえり、あるべきを問いかけて、少しずつ改善するステップを踏まないといけないのだと考えています。
弊チームも色々作ってきましたが、ここから少しずつですが、上記のような課題に取り組んでいければと思います。

最後に、自分のチームメンバーが書いた素敵な記事を紹介します。
本記事は「何が運用を大変にするのか」という点にフォーカスをした記事でした。
以下の記事はそれをどういうチームで解いていきたいのかという話が書かれています。ぜひご参照ください。

https://zenn.dev/loglass/articles/06116430613b82
https://zenn.dev/loglass/articles/5c8712b262b456

株式会社ログラス テックブログ

Discussion