「運用設計の教科書」を読んだ

作者:日本ビジネスシステムズ株式会社,近藤誠司
発売日: 2019/08/23
メディア: Kindle版

運用について教えてもらったり、勉強をしたりすることが今まであまりなかった。経験則でこういったことを考えたほうが良いとか、ここが危なそうなどの勘をきかせていることが多かった気がする。しかし、サービスが開発終わってからやっていることは運用と考えると開発期間よりも長く行うことなので学んでみようと思った。また、以下の文言に同意したことも読もうと思った理由になる。

IT業界で運用の仕事はあまり良いイメージがありません。決まった時間に手順に従って単純な作業をするだけ。関係者感の調整をしているだけ。そのせいで技術もスキルもあまりつかない･･････。社会への貢献に反して、運用に対するマイナスイメージがつきまといます。本当はもっと価値のあることをしているのに。
- 運用設計の教科書～現場で困らないITサービスマネジメントの実践ノウハウ P.1

目次は以下。

1章運用設計とは
2章フェーズから考える運用設計
3章運用業務のケーススタディ
4章基盤運用のケーススタディ
5章運用管理のケーススタディ

本書では運用をシステムを安定稼働させて効率的にサービスを提供することを目標としている。そして、運用設計はサービスの重要度に合わせて運用を最適化することと定義している。
ここで大事なのは

これをしないといけないというものは決まっていないこと
サービスによってやるべきレベルが変わること

上記なのかなと思っている。1年に1回しか必要ないシステムに対して、24時間365日止まったら困るシステムに対してはそれぞれ別の運用設計が必要になるのだろう。なので何かを真似すれば良いと考えるのではなく、それぞれに対しての正解を探し続けることが大事なのだろうと思う。

本書では運用を3つに分類している。

1. 業務運用 システムの業務に関する運用を指す。特に自動化することができなかった、人間がやるべき業務を指す。
2. 基盤運用 システムを維持するための基盤メンテナンスを指す。例えば、OSの定期アップデート、システム監視、不具合対応等。
3. 運用管理
運用に関わる人が守るべきルールと基準を決めること。システムによってルールが違うと利用者の利便性が下がる、運用者の負荷が上がる問題があるためできるだけルールを揃えることが大事。

また、運用設計をすることでの効果が５つ紹介されている。

1. 運用範囲の決定・・・どこまでが自分たちの運用範囲なのかわかる
2. サービスレベルの安定・・・システム停止時間を最小にできる
3. 属人化排除・・・スキルに大きく左右されない
4. サービス品質の安定・・・誰が作業を実施しても同じ結果が得られる
5. ドキュメントの可視化・・・修正対象のドキュメントが明確である

これを読んで自分のチームでは運用の分類をしっかりしていないなと思った。運用と一言でまとめて言っていて、それぞれに対しての自動化する範囲、ドキュメントをどこまで書くかなどをちゃんと決めてないなと反省した。
自動化しろ、ドキュメント書けとは言っているが年1回しかやらないような作業を1ヶ月かけて自動化するなどは無駄なのだろう。それぞれの作業についてやるべきことを決めるのは普段からやっている。
それではなく、やらなくてよいことを決めることが大事だろうなと思った。作業に見合うものなのかを考えながら作業していきたいなと思った。

また本書の中では開発フェーズによって作っておくべきドキュメントの話がされているのが面白かった。開発が終わってから、あとこれを運用しといてねだと運用者に対する負担も大きいと思うし、そもそも運用できるかこんなものというアプリケーション、ツールが出来上がることもあるだろう。
その点、僕が働いているチームでは設計の時点から運用者を巻き込んで運用ができるか、なにができていると運用が楽になるかを一緒に考えてくれている。これは今後もうまくやっていきたいなと思う。

あとがきにあったが、運用には正解がないのだろうなと思う。時代や環境によってやるべきことは変わるだろうし、運用者のスキルによってできるできないもあるだろう。それぞれの運用しているチームで何が良いのかをずっと考えていくしか無いなと思った。ただ、運用ってなんだろう？運用するときに考えなければいけないことはなんだろう？ということを体系的に読めたので良かった。

また、サービス開始後の運用は運用改善としての扱いがあるみたいなので著者の別書になる「運用改善の教科書」を読もうと思う。