03 — Unattended
No. 03
運用
Unattended
運用と聞いて思い浮かぶ仕事の大半は、Athenaraでは発生しません。担当者に残るのは、結果を読むことと、必要なときに方針を一言伝えることだけです。
運用の仕事と、その担い手
i.朝、画面に並ぶ昨夜の結果
担当者が帰ったあとも、Athenaraは調べ続けています。夜のあいだに問いを選び、隔離した環境でプロダクトを動かして確かめ、結果を記録して、また次の問いへ。朝、担当者がすることは、その記録を読むことだけです。
1Reproduced
再現できた問題
昨夜のうちに実際に起こせた問題。同じことをもう一度起こす手順と、その時に観測した証拠が付いています。朝いちばんに読むのは、ここだけで十分です。
2Covered
確かめた範囲
調べて、問題が起きないと確かめられた範囲。何も見つからなかったことも、確認した事実として残ります。
3Still open
まだ確かめていない条件
昨夜は確かめきれなかった状態や前提。放置されるのではなく、次に確かめる問いの候補になります。
4Ahead
これからの見通し
次に何を確かめるつもりか。数週間から数カ月の見通しを、日・週・月の粒度で眺められます。
止まるのは、二つの場合だけ
- a.人が止めたとき
- b.続けられない障害が起きたとき
障害で止まったときは、それを正常な待機のように見せかけず、そのまま画面に示します。朝に画面を開けば、動いていたのか、止まっていたのか、止まっていたなら何が理由かが分かります。見張りを置かずに済むのは、止まったことが隠れないからです。
ii.チャットの一言で伝える方針
管理と呼べる仕事は、
この一言だけ。
Athenaraに何かを頼むとき、専用の操作手順や設定画面を覚える必要はありません。チャットに、ふだんの言葉で書けば通じます。担当者がセキュリティの専門家である必要はありません。何を優先したいかを、自分の言葉で書けば十分です。
チャットは、動かすためのスイッチではありません。何も伝えなければ、これまでの方針のまま調べ続けます。開くのは、会社の事情が変わったとき。新しい決済手段を入れる前、あるサービスを畳むと決めたとき、取引先から質問を受けたときです。
プロジェクトごとの、三つの配分
重点
Focus
調査の機会を優先して回します。新機能の公開前や、気になる変更が入った時期に。
通常
Normal
ほかのプロジェクトと公平に調べ続けます。何も伝えなければ、この状態です。
休止
Paused
そのプロジェクトだけ、新しい調査を始めません。空いた時間はほかのプロジェクトの調査に回り、再開も一言で済みます。
一言が、調査に届くまで
「決済まわりを重点的に見てほしい」
Athenara決済プロジェクトを重点に切り替えました。ほかのプロジェクトは通常の配分のまま続けます。
「このプロジェクトは一旦休止」
Athenara社内ポータルを休止にしました。再開の指示があるまで、新しい調査は始めません。
「ログイン周りは、今どこまで確かめた？」
Athenara確かめた範囲と、まだ確かめていない条件を分けて答えます。記録にある結果から答え、推測では埋めません。
- 1
原文のまま残る
伝えた言葉は、要約で置き換えられずにそのまま記録されます。
- 2
どこに反映したかを返す
どのプロジェクトの、どの調査目的に反映したかを返信します。足りない条件があれば、その依頼への返事として尋ね返します。
- 3
次の問いが寄っていく
以後の調査は、伝えた重点に沿って問いを選びます。途中で失敗した変更を「反映済み」と答えることはありません。
伝えるのは「どこ」まで。「どう」は任せる
一度伝えた方針は、話題を変えても、新しい会話を始めても解除されません。取り消すか、次の方針を伝えるまで有効です。毎朝同じことを言い直す必要もありません。
AIがなぜその調査を選んだかは、作業記録として時系列で残ります。方針が思ったように効いているか気になったら、チャットで尋ねてください。いま何を調べていて、何を待っているかを答えます。
リポジトリの追加や起動方法の設定といった最初の準備だけは、チャットではなく設定画面で人が行います。チャットで頼まれた場合は、その画面と現在の状態を案内します。導入時に一度済ませれば、日々の運用で触る必要はありません。
iii.報告の中身と読み方
警告の一覧を渡されて「どれが本当に危ないのか」を人が調べ直す。静的解析や従来のレビューで生じていたこの仕事を、Athenaraは担当者に回しません。怪しいと思った箇所は自分で動かして確かめ、再現できたものだけを、手順と証拠を添えて報告します。
疑い、確かめ中、再現済みは記録の上で区別され、担当者に「報告」として届くのは再現済みだけです。試して起きなかったものは、どの条件で起きなかったかとともに「確かめた範囲」として残ります。静的解析で判定できなかったものも「問題なし」とはせず、判定できなかった理由とともに残します。
一件の報告に書かれていること
Specimen記載例。実在の報告ではありません。
1何が起きるかSummary
ログインした利用者が、画面のアドレスにある注文番号を書き換えると、他人の注文内容を表示できます。
問題を一文で。事業として放置できるかは、ここと下の条件で判断できます。
2再現手順Steps
- 利用者Aでログインし、自分の注文詳細を開きます。
- アドレス末尾の注文番号を、利用者Bの注文番号に変えます。
- 利用者Bの注文内容が、そのまま表示されます。
同じことをもう一度起こすための操作。開発者に渡せば、手元で同じ現象を確かめられます。
3証拠Evidence
手順3で実際に返ってきた画面と通信の記録。利用者Bの氏名と配送先が含まれていました。
試した時に観測したもの。「起きるはず」という推測ではなく、起きたという記録。
4確かめた条件Conditions
隔離環境で起動したプロダクトに対し、一般の利用者の権限で試しました。どの版のコードを試したかも結び付いています。
どの範囲で成り立つかを読む箇所。影響の広さを見積もる材料になります。
5まだ確かめていない条件Not yet checked
法人アカウントや管理者の権限で同じことが起きるかは、まだ試していません。
「問題なし」とは書かない範囲。次に確かめる問いの候補として残ります。
読んだあと、誰が何をするか
Business owner
事業の責任者
- 「何が起きるか」と「確かめた条件」で、事業への影響を読み取ります。
- 直す順番を決めます。急ぐものがあれば、チャットで重点を伝えてください。
- 報告が本当かを確かめるために、別の調査を手配する必要はありません。
Development lead
開発の責任者
- 再現手順と証拠を、そのまま担当の開発者に渡します。
- 開発者は手元で同じ現象を起こし、原因を追って直します。
- 直したあとの確かめ直しは、Athenaraが同じ条件で行います。
iv.直したあと、同じ条件での試し直し
報告を受けて、開発者が修正を入れます。多くの会社では、ここで話が終わるか、次の診断まで持ち越されます。本当に直ったのかを確かめる人も、確かめる時間もないためです。
一件の問題がたどる道
1Athenara
再現する
隔離環境で問題を実際に起こし、手順と条件と観測を記録。
2Athenara
報告する
再現手順と証拠を添えて、担当者のもとへ。
3Developer
直す
開発者がいつもどおり修正し、コードを更新。再確認の依頼は要りません。
4Athenara
試し直す
更新を取り込み、前の結論が今も当てはまるかを、同じ条件で確認。
5Athenara
記録に加える
直ったのか、まだ起きるのかを、新しい観測として記録。
過去の記録は、上書きしない
直ったからといって、見つかった時の記録を消したり書き換えたりはしません。試し直した結果は、新しい観測として横に加わります。一件の問題について、いつ見つかり、いつ直り、何をもって直ったと言えるのかを、あとから証拠でたどれます。
結果が結び付くのは、実際に試した版のコードだけです。あいだに入った変更まで、まとめて「確認済み」とはみなしません。直ったと記録された問題は、その版で、その条件で確かめたという意味を持ちます。
直ったあとも、見張りは要らない
一度直った問題が、
別の変更で戻ってくる。
開発の現場では珍しくないことです。年に一度の診断なら、それに気づくのは次の診断になります。
Athenaraは、コードが変わるたびに、過去の結論が今も当てはまるかを確かめ直すべき問いとして拾い上げます。見つけた時の再現手順が残っているので、同じ問題が戻ってきていないかを同じ条件で試せます。戻っていれば、再び報告として届きます。人がリストを作って定期的に見直す必要はありません。