本稿は「構造振動モデルによるソフトウェア設計の理解」の続編である。前稿では、更新され続けるソフトウェアの揺れを、束、入口、縮退、出口という共通形式で捉えた。束は同じ判断原理で扱う範囲、入口は運用上観測された現象、縮退は複数の候補を条件付きで一つの扱いへ寄せる操作、出口はその結果として選ばれた実装または運用である[1]。
この形式だけでは、揺れを記述できても、どの入口を見直すべきかは決まらない。必要なのは、入口の解釈、縮退方向、所属する束が短期間に何度も変わっている箇所を見つけ、入口の記述と束境界を小さく修正する運用である。
本稿では、入口を一行で記録する「入口データベース」に、問題分類、縮退変更回数、再入回数を加える。これらは物理量としての振幅を測るものではない。設計判断の往復と、解消したはずの問題の再出現を、見直し対象として抽出するための代替指標である。指標の目的は状態を精密に数値化することではなく、入口の分割、束の移動、責任分界の修正、退避路の終了という次の操作を決めることにある。
入口データベースは特定の製品名ではない。テキスト、表計算、Issue管理システムなど、検索と履歴確認ができる場所に、一つの入口を一行で記録する運用を指す。
1. 振幅を計測可能な変化へ置き換える
構造振動の振幅は、CPU使用率や応答時間のように直接測定できる量ではない。入口の説明が何度も書き換えられる、同じ現象が異なる束を往復する、縮退方向が短期間に反転する、閉じた入口が再び開くといった変化を通じて間接的に観測する。
ここで数えるべきなのは、議論の件数や発言数ではない。議論が多くても、再現条件が明らかになり、責任分界が固定され、縮退方向が収束しているなら増幅しているとは限らない。反対に、議論が静かでも、入口が記録されず、監視を止めたために再発が見えなくなっただけなら減衰したとはいえない。
監視項目は、異常を表示するだけでなく、受け手が実行できる操作へ結び付いていなければならない。GoogleのSRE文献も、監視を定量的な情報の収集と処理として扱い、通知や可視化を運用上の行動へ結び付ける必要を示している[2]。入口データベースの指標も同じであり、値が変わったときに何を更新するかを先に決める。
指標を増やしすぎると、入力負荷が観測の継続を妨げる。SRE Workbookでは、取得可能なデータを無差別に集めるのではなく、監視の目的を明確にし、変更前後を比較できる情報を残すことが重視されている[3]。入口データベースでも、次の判断に使わない項目は追加しない。
2. 入口の一行に残す情報
一行の入口には、現象名だけでなく、再現条件、所属する束、現在の縮退方向、責任者、状態、退出理由、更新日を残す。さらに、問題分類、縮退変更回数、再入回数を加える。現在値だけを上書きせず、変更履歴を追跡できることが必要である。構成基準と変更履歴を管理し、承認された状態からの差異を監視する考え方は、構成管理の基本にも一致する[4]。
| 項目 | 記録内容 | 判断への使い方 |
|---|---|---|
| 入口 | 観測された現象を、対象と条件が分かる一文で記録する。 | 同じ現象を別名で重複登録していないか確認する。 |
| 再現条件 | 環境、構成、操作、発生時期など、成立範囲を限定する条件を記録する。 | 条件が混在している場合は入口を分割する。 |
| 束 | 同じ責任主体と変更理由で扱う入口群を記録する。 | 束の移動が続く場合は境界または責任分界を見直す。 |
| 問題分類 | Aは設定、Bは構造、Cは運用、Dは外部境界として一つを記録する。 | 分類変更が続く場合は、観測不足または複数入口の混在を疑う。 |
| 縮退方向 | 現在採用する設定、実装、回避手順、既定経路を記録する。 | 変更が続く場合は、束境界、終了条件、退避路を見直す。 |
| 責任者 | 入口を更新し、次の判断を行う主体を記録する。 | 責任者が定まらない入口は、責任分界そのものを見直す。 |
| 状態と退出理由 | 観測中、対応中、退避中、終了を記録し、終了時には理由を残す。 | 再発時に、真の解消か観測停止かを判別する。 |
| 三つの変化 | 分類変更回数、縮退変更回数、終了後の再入回数を記録する。 | 設計判断が往復している入口をレビュー対象として抽出する。 |
AからDまでの分類は「象限」と呼ばない。二本の軸から四領域を導く分類ではなく、本稿が運用上定める四つの問題型だからである。Aは設定値、権限、起動順、実行環境などの差で生じる問題、Bは責任分界、依存方向、抽象化層など設計の骨格に関わる問題、Cは手順、監視、教育、更新運用の不足で生じる問題、Dは機器、ドライバー、外部サービス、利用者環境など管理境界を越える条件に依存する問題とする。
分類は原因を確定する診断名ではなく、最初に調べる範囲を決める仮説である。AからBへ変わったことを進歩、Bに固定されたことを収束と機械的に評価してはならない。分類変更が続く事実だけを、入口の条件や束境界を見直す契機として使う。
退出は一つの入口について通常一度しか起こらないため、「退出頻度」を入口単位の振幅指標にはしない。退出時には、恒久対応、別入口への統合、対象外化、観測終了などの理由を残す。その後に同じ入口を再び開いた回数を再入回数として数える。これにより、問題が解消したのか、見えなくなっただけなのかを区別できる。
3. 三つの変化から増幅を読む
三つの回数に共通の絶対閾値は設けない。入口の種類、更新頻度、運用期間が異なれば、同じ回数でも意味が変わるためである。直近のレビュー期間と過去の状態を比較し、変化が集中している入口を抽出する。
| 観測された変化 | 最初に疑うこと | 最初の操作 |
|---|---|---|
| 問題分類が短期間に変わる | 再現条件が不足しているか、別の現象を一つの入口に混ぜている。 | 条件を追加し、原因候補が独立している場合は入口を分割する。 |
| 縮退方向が短期間に反転する | 採用条件、終了条件、責任分界のいずれかが曖昧である。 | 縮退を選ぶ条件と戻す条件を記録し、必要なら退避路へ分離する。 |
| 終了後の再入が続く | 退出理由が誤っているか、観測停止を解消と扱っている。 | 過去の退出理由を確認し、終了条件または監視条件を書き換える。 |
| 同じ入口が複数の束を移動する | 束の境界が表面的な機能名で切られ、変更理由や責任主体と一致していない。 | 入口を分割するか、同じ変更理由を持つ入口を一つの束へまとめる。 |
| 特定の束だけで三つの回数が増える | 束が広すぎるか、更新責任が一人または一部署に集中している。 | 束の分割、責任者の追加、既定経路と探索経路の分離を検討する。 |
この表は原因を自動判定する規則ではない。同じ変化でも、実際の原因は入口ごとに異なる。表が担うのは、レビューで最初に確認する箇所と、最初の小さな操作を固定することである。
4. 指標を更新判断へ接続する
入口データベースの制御ループは、観測、判断、更新、検証の四段階で構成する。観測では三つの変化と状態遷移を見る。判断では入口を分割するか、束を移すか、縮退条件を変えるかを決める。更新では一行の条件、責任者、退避路、退出理由を書き換える。検証では次のレビュー期間に同じ変化が減ったかを確認する。
指標は更新を命令するものではない。分類変更回数が増えたから直ちに束を分割するのではなく、変化の履歴と再現条件を読み、どの更新が必要かを判断する。数値だけで操作を決めると、入口を細分化しすぎたり、再入を避けるために終了を記録しなくなったりする。指標は判断の入口であり、評価目標ではない。
更新後の検証には、変更前の状態を残す必要がある。入口の現在値だけを上書きすると、縮退方向を変えた結果として再入が減ったのか、観測条件が変わって見えなくなったのかを判別できない。変更理由、変更者、変更日、変更前後の値を履歴として残す。
束の境界は、利用者から見た機能名ではなく、同じ変更理由と責任主体を持つかで決める。Parnasは、処理手順の段階ではなく、変更され得る設計判断を隠蔽する単位でモジュールを分解する考え方を示した[5]。入口データベースでも、同じ理由で一緒に変更される入口を同じ束へ置き、独立に変更できる入口を分ける。
5. 退避路と責任分界を同時に管理する
縮退方向が安定しない入口を、既定経路へ混ぜたまま探索すると、暫定的な条件分岐が恒久化する。反対に、不安定であることを理由に探索を止めると、未確認の条件を残したまま既存方式へ固定される。退避路は、この二つを分けるために、探索中の方式を既定経路から外して条件付きで利用できるようにする。
退避路には、利用条件、責任者、観測項目、既定経路へ移す条件、廃止条件を記録する。「念のため残す」だけでは終了できない。縮退変更が一定期間なく、再入が発生せず、既定経路で必要な条件を満たしたと確認できた時点で、昇格または廃止を判断する。
責任分界も入口の一行に置く。自分の系が保証する範囲、外部へ依存する範囲、利用者側で確認すべき条件を分ける。完全な境界を最初から確定できなくても、暫定線を置き、境界を越えた事実が見つかったときに更新する。責任線がない入口は、誰も更新せず、同じ現象が複数の場所で別名の問題として再登録されやすい。
一つの入口に複数組織の対応が必要な場合でも、入口の更新責任者は一人または一つの役割に固定する。更新責任と解決責任は同じでなくてよい。更新責任者は、条件、状態、退出理由、参照先が最新であることを維持する。
6. 週次レビューで境界を小さく直す
レビューは週次または隔週で行い、全入口を読み上げない。前回以降に問題分類、縮退方向、状態、所属する束が変わった入口と、再入した入口だけを対象にする。個別障害の根本原因分析や実装案の詳細検討は別の場で行い、入口データベースのレビューでは記録と境界の修正に限定する。
各入口のレビュー結果は、入口の書き換え、入口の分割または統合、束の移動、責任者の変更、退避路の追加または終了、退出理由の修正、変更なしのいずれかにする。議論だけを残して次回へ送る場合も、未確定の条件と次の観測項目を一行へ追記する。
Waylandに関する入口では、Waylandを一律に境界問題へ分類しない。Waylandはコンポジターとクライアントの通信を定め、入力処理もコンポジターを経由する構造を持つ[6]。実際の入口には、コンポジター、クライアント、セッション、入力方式、ドライバー、機器、再現操作を分けて記録する。設定値の誤りならA、プロトコルや責任分界の問題ならB、手順不足ならC、機器やドライバー依存ならDとなり得る。
systemdに関する入口も、一律に構造問題へ分類しない。systemdは依存関係に基づくサービス管理、プロセス追跡、ログ管理などを提供する[7]。入口には、対象unit、依存関係と順序、実行ユーザー、環境、上書き設定、関連ログを記録する。記述場所や権限の誤りはA、unit間の責任分界や依存方向はB、配備・再起動手順の不足はC、外部機器や別サービスとの境界はDとして調べる。
このように、対象製品を先に分類するのではなく、観測された入口ごとに条件と責任範囲を分類する。同じ製品でも問題型が異なれば、最初に行う操作も異なる。
7. 振動が消えなくても増幅は抑えられる
入口データベースを計測器に変えるとは、抽象的な振幅へ一つの数値を与えることではない。問題分類、縮退方向、所属する束、終了後の再入という変化を履歴として残し、設計判断が往復している入口を見つけることである。
増幅の兆候が見つかったとき、最初に行うのは大規模な設計変更ではない。再現条件を狭め、混在した入口を分割し、変更理由に合わせて束を動かし、責任者と退避路の終了条件を記録する。更新後には、同じ変化が減ったかを次のレビューで確認する。
成熟した構造は、振動が発生しない構造ではない。変更理由と履歴を失わず、問題が再出現したときに過去の条件、縮退方向、退出理由を再展開できる構造である。入口の一行がその記録を保ち、小さな境界修正を継続できるなら、揺れは残っても出口の分岐と議論の再演は増幅しにくくなる。
参考文献
- id774, 構造振動モデルによるソフトウェア設計の理解（2026-02-24）. https://blog.id774.net/entry/2026/02/24/3804/
- Rob Ewaschuk, “Monitoring Distributed Systems,” in Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, eds., Site Reliability Engineering, O’Reilly Media, 2016. https://sre.google/sre-book/monitoring-distributed-systems/
- Jess Frame, Liz Fong-Jones, Kent Rancourt, “Monitoring,” in Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne, eds., The Site Reliability Workbook, O’Reilly Media, 2018. https://sre.google/workbook/monitoring/
- Kelley Dempsey et al., “Guide for Security-Focused Configuration Management of Information Systems,” NIST Special Publication 800-128, 2011, updated 2019. https://doi.org/10.6028/NIST.SP.800-128
- David L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules,” Communications of the ACM, Vol. 15, No. 12, pp. 1053–1058, 1972. https://doi.org/10.1145/361598.361623
- Wayland Project, “Wayland Architecture,” Wayland Documentation. https://wayland.freedesktop.org/docs/html/ch03.html
- systemd Project, “systemd,” systemd.io. https://systemd.io/