運用業務における人と組織のエラー

【IIJ 2024 TECHアドベントカレンダー 12/21の記事です】

はじめに

こんにちは。普段はIIJ のとあるサービスのインフラ運用をしています。
運用業務をしていくなかで日々沢山のトラブルに巡り合いますが、トラブルや失敗の原因は必ずしもシステム的なものだけではありません。
では何が原因か？私たちエンジニア自身が引き起こす、人と組織のエラーです。
今回は私と同じようにインフラ運用を担うエンジニアに向けて、私が運用業務をしていて巡り合った苦い経験を紹介します。

概要

私のチームでは月1で設備のリソース使用状況の推移を確認しています。
ある月、運用しているサーバ群のストレージ容量の使用率が規定値を超え増加傾向にあり、詳細を調査したところ将来的にストレージ容量不足になることが判明しました。
そこでデータ保管用のホストを増設することにしました。早速、物理サーバの払い出しや、必要なホストの設計、構築を進めました。
物理サーバの払い出し後、仮想マシンの払い出しが従来通りの手順でできないというアクシデントがあったものの、みんなの頑張りがあって無事増設は終わりました。

・・・数か月後。
増設したデータノードについて過剰にリソース割り当てられていると指摘を受けました。 一体何が起きたのでしょうか。

背景

この話には2つの背景があります。

1つは、これは複数のチームにまたがったものであることです。
実は私のインフラ運用部隊は、業務内容ごとにいくつかの組織に分かれています。今回は登場する組織のみを紹介します。
※ わかりやすくするため今回のホスト増設業務においてそれぞれが持つ役割のみ記載します

– チームA：私が担当したホストの設計をする組織
– チームB：物理サーバのアサイン、仮想マシンの払い出しを行う組織
– チームC：仮想マシンの構築を行う組織

ホストの増設はこの3つのチームが協力し合って行ったものです。
具体的にはチームAが計画を行い、ホストを設計。チームBとCに依頼を出して後続の作業を進めたのでした。

もう1つは、増設に使った物理サーバは今まで使っていたサーバよりも新しい世代であり、私のサービスでは初めて使うものだったということです。
これにより既存の手順では仮想マシンの払い出しができませんでした。
そして何より、新しい世代ということでマシンが大幅にスペックアップしていました。

振り返って

背景を踏まえて起きたことを振り返ってみると、「今までと異なる物理サーバを使う」ことを踏まえて設計すべきでした。
しかし実際には設計には反映できず、考慮漏れとなってしまいました。

なぜ起きたか

振り返ってみるとこの問題が発生した原因はさまざま思い当たるのですが、今回は組織と人に焦点を当ててみます。
以下の切り口から私が担当したチームAの立場に立って原因について考えます。

①  組織間の問題
②  組織内の問題

また原因について考える前に、わかりやすいよう時系列を以下に示しておきます。

• 2024年5月初旬
  • チームAがデータ保管用ホストの増設を決定
• 2024年5月中旬
  • チームAからチームBへ物理サーバのアサイン、仮想マシンの払い出しを依頼
  • チームAからチームCへ仮想マシンの構築を依頼
  • チームBからチームAへ仮想マシンの払い出し完了が遅れる旨の連絡
• 　2024 年6月
  • ホストの増設完了

① 組織間の問題

チームAでの設計完了後、設計内容をパラメータシートという形に落とし込み、チームBへ構築を依頼しました。
このときに組織間の認識齟齬がありました。

チームAからすると「従来通りの手順で従来のサーバ上にホストを構築する」という認識で依頼しており、一方でチームBは「（サーバの在庫状況を鑑みて）従来通りの手順で新しいサーバ上にホストを構築する」という認識をしていました。
この認識齟齬が生まれた理由として、お互いの組織の前提となる情報に乖離があったからだと考えています。

チームAとしては「チームBから何も言われていないので通常通りのホストを作ってくれる」と考えていました。
一方でチームBは「チームAの設計が終わっているのだから、与えられた設計通り払い出しを遂行すればよい」という認識をしていました。

さらに背景を深堀すると、チームABCという体制ができてまだ数カ月であり、チーム毎の役割やコミュニケーションの立て付けにあいまいな部分が残っていました。
そもそも設計が終わってから依頼を行うという業務フローになっていましたが、業務工程別ではなく業務領域別に役割分担をしているので、フロー自体に考慮が不足していました。

また情報共有に使用したパラメータシートについても、旧来の体制時に使っていたものをそのまま流用しており、VM部分の設計結果をチームAが、物理部分の割り当て結果をチームBが埋めるという形になっていました。またリソースの割り当て部分は「100%を割り当てる」となっていたのも問題でした。

② 組織内の問題

1週間後、チームBより「仮想マシンの払い出し完了が遅れる」という連絡が来ました。
理由は「新しい世代の物理サーバになるため、従来の仮想マシン構築手順では構築できない」からでした。
このタイミングで初めてチームＡは「今までと異なる物理サーバを使う」ことを知ったのですが、ここでも問題が起きました。
自分たちが設計した内容に見直しが必要であることに気づかなかったのです。
その背景としては、「構築が遅れるので、それまでストレージが持つかどうか確認して対処しないといけない」など別のことに気を取られてしまったことや、チームＡとしては設計フェーズが完了していたので設計という観点が頭から欠落していたことがあります。
今起きていることやこれからのことはイメージできたのですが、すでに終わったと思っていることについては意識がおよびませんでした。

対策

対策としては現在も取り組み中です。
チーム内への事例の共有、業務フローの改善やそもそもの設計レビュー時に気づく仕組み（レビュー観点表の整備）に努めています。

おわりに

組織で何かを成し遂げることの難しさ

エンジニアらしからず人にまつわる話をしましたが、あなたはどう思ったでしょうか。
人が1人で出来ることには限りがあり、何か大きなことを達成するには複数人で協力する・組織で動く必要があります。
しかし組織では立場が違い見えているものも向いている方向も違うため、うまく意思伝達ができず、目標達成から大きくそれてしまうことがあります。
また組織間に限らず、人と人という最小単位のコミュニケーションにおいても同じことが起こりえます。

そうならないようにするには、どうしたらよいでしょうか。私は以下が大切だと考えています。

• 双方で共通認識を持つこと
  • コミュニケーションにおいて前提をそろえたり目標を示すことで向いている方向や持っている情報をそろえる
• 認識のずれや見落としを想定すること
  • コミュニケーションミスや情報の見落としは誰にでも起こりえると認識し、チェックシートなど人によらない対策を設ける

正解はないと思いますので、ぜひ自分で考えたり、他の人の意見を聞いてみたりしてみてください。
最後になりますが、みんな私と同じ失敗はしないように気を付けてくださいね！