はじめに

こんにちは、IT戦略部 滝です。

この記事では、最近対応したDevin Enterpriseの運用自動化を通して、運用設計の考え方や方法論について共有します。 プログラムの実装やコードの書き方については色んな記事や書籍がありますが、運用設計を初めて行う際には、どの記事や書籍を読めば良いかわからなかった。という個人的な経験があります。 運用設計を進める上での考え方や方法論について本記事を通して共有することで、運用設計をこれから初めて行う方の参考になればと思います。

この記事では、まず「運用設計の流れ」を方法論としてまとめたあと、Devin Enterpriseの案件を通じてそれを実践した話を書きます。方法論パートと実践パートを分けることで、実践パートでは「ここでこう判断した」「ここで詰まった」というエピソードを腰を据えて書けるようにしました。

最初に注意しておくと、AIの話は出てきません。 Devin Enterpriseと聞いてAIの話を期待された方には恐縮ですが、今回は運用設計の話に焦点を当てています。

運用設計の流れ

運用設計は、大きく以下の流れで進めます。

1. 目的やゴールに関する認識を合わせる
2. 現在の運用を把握する
3. 全体像を可視化する
4. 担当を決める（責任分界・運用一覧）
5. 運用の構築をする（実装・手順・合意）

目的やゴールに関する認識を合わせる

最初に行うことであり、運用を設計する上で1番大切なことです。ここでの認識のズレは後々大きな手戻りの原因になるので、時間をかけてでもしっかりと認識を合わせることが重要です。 まずは、現在運用を担っている部門がどのような世界観を実現したいか？そのために解決したい課題は何か？をヒアリングし、文章などで合意を取っていきます。

「言葉では合意したつもりが後から認識がズレていた」ということがあります。口頭で確認したと思っていても、文章に落とすことで曖昧だった部分が表面化することがあります。面倒に感じても、合意を文章で残すことを習慣にすることを推奨します。

現在の運用を把握する

ヒアリングおよび対象システムの調査結果から、自分の言葉に置き換えて説明できるようにします。 説明できなければまだ自分が理解できていないことになるので、どのような情報が足りないかを埋めていきます。

気をつけることは、ヒアリング先の担当者が前提知識として持っている情報を、こちらが知らないまま話を進めてしまうことです。わからない言葉はその場で確認しながら進めると良いです。

全体像を可視化する

文章や口頭の説明だけでは、複雑なシステムの全体像を正確に頭に入れることは難しいです。図を起こすことで、情報の抜け漏れや誤解に気づきやすくなります。

図に何を含めるかも重要です。目的に応じて情報を絞ることで、伝えたいことが明確になります。たとえば「なにがどこへ行くか」に絞りたいなら、「誰が」という情報は別の図に譲ると良いです。

担当を決める

運用を誰が担うかを明確にします。担当が曖昧なままだと、問い合わせや障害が発生した場合に対応が遅れる原因になります。

責任分界をまとめたうえで、実際にどのような運用が必要になるかを洗い出し、運用一覧にまとめます。担当の全体像が見えている状態で洗い出すと、当初想定していなかった運用項目が見えやすくなります。

運用の構築をする

担当と運用一覧が決まったら、実際に運用の構築を行います。運用の構築は以下の3つのステップで行います。

1. 自動化処理の実装を行う
2. 運用手順を記載する
3. 成果物の合意を取る

自動化処理の実装では、優先度の高い機能から実装することと、エラー発生時の復旧手順をセットで考えることを意識します。エラーメッセージを書く際は、「どこへ誰が何をすれば良いか」をセットで考える必要があります。ログに「400 bad request」とだけ出力されても、運用者は何をすれば良いかわからないですよね。

運用手順は、開発者が忘れがちなものです。システムだけ作っても業務は回りません。特に複数部署が関わる運用項目は、何を起点として誰がどのような運用を行うかを明記する必要があります。

成果物の合意は、可能であれば少しずつ取ることが結果的に早くなることが多いです。機能が多くなれば一度の打ち合わせで確認することは難しくなり、また言葉や図で説明するよりも実際に動くものを見せる方が圧倒的に認識を合わせやすいからです。

題材: Devin Enterpriseのプロビジョニング自動化

ここからは、上の流れを実際のDevin Enterpriseの案件で実践した話を書きます。

目的やゴールに関する認識を合わせる

Devin Enterpriseをメインで運用しているIT基盤部¹に要件をヒアリングしたところ、実現したい世界観を要約すると以下でした。

1. GoogleGroupのメンバーとDevin EnterpriseのSub-Organization内のユーザを同期し、GoogleGroup毎にDevin Enterprise上のロールを分けたい
2. GoogleGroupのメンバーとSlack上のDevin Enterprise用ワークスペース及びチャンネル内のメンバーを同期したい

2の機能は、既存の内製システムのサンゴ²とHERB³で実現できるため、今回は1の機能を実装することになりました。

現在の運用を把握する

1を掘り下げていくと、Devin Enterpriseの実装と現在の運用はこのようになっていました。 (後の図を見てから読むことを推奨します)

• Devin Enterpriseでは2階層までOrganizationを作成できる
• 2階層目のOrganizationは、Sub-Organizationと呼ばれている
• Devin Enterpriseへのユーザアカウントの招待は1階層目のOrganizationに対して行い、Sub-Organizationへは所属という形で表現される
• Devin Enterpriseを利用するユーザアカウントが1つのGoogleGroup(以下root_google_groupと記載)の配下に入っている
• Sub-Organizationのユーザ・ロール別にroot_google_groupの配下にGoogleGroupが作成されている
  • 1つのSub-Organizationに対して、ロールの数だけGoogleGroupが作成されている
• ユーザの追加・削除は、root_google_groupの配下のGoogleGroupに対して行われている

当初、「プロビジョニングの自動化」と聞いていたため、IT戦略部側でユーザアカウントの招待とSub-Organizationの作成・管理の両方を自動化することを想定していました。しかしヒアリングを重ねるうちに、Sub-Organizationの設計・管理はDevin Enterprise全体の利用方針に関わるためIT基盤部が担当するものであることが明確になり、担当の引き方を再検討することになりました。

全体像を可視化する

さて、前段で自分の言葉で説明できるようにする、と記載しましたが、先ほどの箇条書きを文字か口頭で説明されて頭に入っていくでしょうか？ 私は入らないので図を起こします。

今回のDevin Enterpriseのユーザデータの連携イメージはこのような感じになります。

連携を担うサンゴとHERBのシステムが含まれていないのは、この図ではあくまで最終的にどのデータがどこへ連携するかに焦点を当てたいためです。 現時点では、誰がという情報は重要ではなく、あくまでなにがどこへ行くかという情報に注目したいと考えたため、図には入れていません。

担当を決める

責任分界をまとめる

Devin Enterpriseの運用は、このプロビジョニング自動化を行うまで、IT基盤部が全て行っていました。しかしプロビジョニングの自動化にあたってIT戦略部が関わることになり、誰がどこに対して責任を持つかを決める必要がありました。

「同じ会社なのに担当を分ける必要があるの？」と思われるかもしれません。しかしこれは、運用が始まってから議論すると痛い目を見る話です。過去にいた会社で、サービスが稼働し始めてから追加の運用が必要になった際、担当が曖昧だったせいで「なぜ自分たちがやらなければいけないのか」という議論になったことがありました。稼働後に担当を議論することになると、対応が遅れるだけでなく関係者間の関係も悪化しやすいです。だからこそ、運用が始まる前に担当を明確にしておくことが大切です。

今回の議論では、Sub-Organizationの作成をどちらの部署が担うかが論点になりました。Sub-Organizationの設計・管理はDevin Enterprise全体の利用方針に関わることから、IT基盤部が担当することが適切と判断しました。結果として、IT基盤部とIT戦略部間での責任分界は以下となりました。

• IT基盤部
  • Devin EnterpriseのSub-Organizationの作成と管理
  • Devin Enterpriseと連携するためのGoogleGroupの運用
• IT戦略部
  • Devin EnterpriseのOrganizationへのユーザアカウントの招待
  • Devin EnterpriseのSub-Organizationに対するユーザアカウントとロール紐付け

運用一覧を作成する

責任分界が決まったので、実際にどのような運用が必要になるかを洗い出します。 ここでも、上に書いたような図があるとどのような運用があるか想像しやすくなります。

No.6とNo.7は、当初のプロビジョニング自動化のスコープには入っていませんでした。サービス開始直前になって、「新しいRoleが追加されたときはどうするか」「システムアカウントはどう扱うか」という観点が抜けていることに気づき、急いで追加しました。

この2つの運用項目は変更頻度が低いと考えたため、自動化の対象外として手順書の整備のみに留めました。「どれを自動化するか」を判断する際の一つの基準は、変更頻度と自動化コストのバランスです。頻繁に発生する運用ほど自動化の費用対効果が高く、稀にしか発生しないものは手順書で対応する方が現実的な場合もあります。

運用の構築をする

自動化処理の実装を行う

自動化処理で実装することは、運用項目のNo.4とNo.5です。

今回は全ての自動化機能をまとめて一度にリリースしました。本来であれば、優先度の高い機能からリリースすることで運用者の負荷を早期に下げたり、フィードバックを早く得たりできます。ただ今回は、関係者間の調整やスケジュールの都合から、まとめてリリースするという判断になりました。理想的な進め方ではなかったと振り返っています。

実装において特に意識したのは、エラーが発生した場合に復旧手順は何をすれば良いかをセットで考えることです。処理を自動化する際に1番悩ましいのが、エラーが発生した場合の対応です。自動化処理を実装していると、WebAPIや、データの不整合など様々な理由でエラーが発生する可能性があります。 さて、その場合にエラーメッセージはどのようにするのが良いでしょうか？ ログに「400 bad request」とだけ出力されても、運用者は何をすれば良いかわからないですよね。 エラーメッセージを書く際は、どこへ誰が何をすれば良いかをセットで考える必要があります。

運用手順を記載する

開発者は忘れがちなことですが、システムだけ作っても業務が回るわけではありません。 今回のケースでいえば、No.6,No.7の運用項目は、頻度が少ないものと考え、運用自動化の対象外としています。 そのうえ、IT基盤部とIT戦略部の両方が関わる運用項目になっているため、何を起点として、誰がどのような運用を行うかを明記する必要があります。 また、今回は作成しませんでしたが、運用に関わる部署が3つ以上になるなら運用フローを記述した方が良いです。

成果物の合意を取る

運用の構築ができたら、成果物の合意を取ります。自動化した処理の内容と、運用手順に記載した内容で実際に業務が回るかを確認します。 この確認をするための環境は、テスト用の環境でも本番の環境でも構いませんが、本番の環境で確認する場合は、業務に支障が出ないように注意する必要があります。

今回のDevin Enterpriseのプロビジョニング自動化では、No.4とNo.5をそれぞれ本番環境で確認しました。

No.4のユーザの招待は、まずDry-Runで意図しないユーザが招待されないことを確認しました。このDry-RunでいくつかのSub-Organizationで既に招待されているユーザが、対応するGoogleGroupには存在していないケースがあり、同期処理の結果としてそのユーザがSub-Organizationから削除される対象になりかけていたのです。確認の結果、当該ユーザはSub-Organizationから外れていて問題ないことが分かりました。本番での確認前に必ずDry-Runを行うことの大切さを改めて実感した場面でした。

No.5のユーザアカウントへのSub-Organizationのロール付与は、IT基盤部の方が利用しているSub-Organizationに対してのみ自動化処理を有効にすることで、既に利用しているエンドユーザに影響が出ないように段階的に確認を行いました。

自動化した処理結果および運用手順の内容について、IT基盤部とIT戦略部で読み合わせを実施し、最終合意をとることができました。 可能であれば、少しずつ成果物の合意を取ることが結果的に早くなることが多いです。機能が多くなれば一度の打ち合わせで確認することは難しくなり、また言葉や図で説明するよりも実際に動くものを見せる方が圧倒的に認識を合わせやすいからです。

まとめ

今回の内容は私が運用設計を進める上で大切にしていることなどを、Devin Enterpriseの運用設計を通して紹介しました。 最後に、システムを動かし続けていくうえで大切なのは、以下の２点と考えてます。

1. 初期運用の担当者がいなくなったとしても、運用が回り続けるようにすること
2. どのような考えで運用設計を行ったかを残すこと

運用設計がいい加減でも、初期運用の担当者がいると、その方は業務を理解しているため、案外運用は回ってしまいます。しかし、数年経って担当者が変わった途端に運用が回らなくなってしまうことはよくある話です。 そして、数年後に業務が運用と乖離し、運用を見直す際に、どのような考えで運用設計を行ったかがわからないと、見直すことも難しくなります。

個人的な経験からですが、運用設計は続けやすく変えやすい設計にすることが大切だと考えています。

運用設計に正解はありませんが、読んだ方にとって運用設計を進める上での考え方や方法の参考になれば幸いです。