今月の振り返り

仕事 #

休日のデータ連携点検を仕組みにした。サブエージェントの並列調査を 11 担当まで広げ、記録先を 1 つのイシューに統一し、毎朝の定点観測は cron に載せた。自分は総括と判断だけをやる形にできた
点検を仕組みにしたことで、手が回っていなかった構造的な不具合に着手できた
- 鮮度の判定に使う時刻が主キーの初回観測時刻に固定される不具合を 1 行で修正した（監視対象 233 モデルのうち 203 モデル、17,377 行が影響）
- データ取得ジョブの起動を共有店舗ごとに畳み込み、143 本から 90 本へ減らして 7 日間の失敗 0 本を確認した
- 配送状況の取得がクォータに当たる原因は、上限ではなく 369 件を 102 秒で連打する実装だった。間隔を入れて構造から直した
- 配送業者の 1 社がずっと取得できていなかった原因を実測で特定した。サーバーが前方秘匿性のない鍵交換しか受け付けず、言語のランタイムが既定から外した暗号スイートだったためで、半年前の移行時から壊れていた
- 広告 API が数値で返す項目を取り込めない不具合を直し、4 アカウントが半年ぶりに復旧した
- 個人情報のハッシュ化処理が条件式の誤りで 7 ヶ月間まったく動いていなかったことを見つけた
外部サービスのメンテナンスで定時実行 143 本が全滅した日は、同日中に全件を再実行して復旧させた
メモリ不足で落ちていたジョブを、一時ファイルをクラウドストレージへ退避する形で恒久対応した。欠損していた 6 日分も回収し、7 日間の観測で完了させた
通知が届かない不具合を接続の再利用で解消し、受理数が 128 件から 284 件へ倍増したことを実測で確認した。回避策として検討していたネットワーク設定の変更は不要と分かった
秘密情報の管理を立て直した。値が未登録のままデプロイが落ち続けていた状態を解消し、古いリビジョン 44 本を削除して露出を止め、引き継ぎ用の権限まで整えた
依存関係を棚卸しし、未処理の更新 10 件を並列検証して全件マージした。脆弱性アラートは 480 件から 262 件（重大なものは 48 件から 7 件）まで減った
静的解析を導入し、検出された 237 件を「慣例的に除外するもの」と「実際に直す価値があるもの」に切り分けた
あるクライアントのサーバーで PHP を更新し、途中で 37 分の障害を出したあと設定ファイルの退避分から復旧させた。あわせて停止していたサイトを棚卸しし、移行コストを実測から見積もった
認証情報が社内の 2 箇所で別管理されていることが、繰り返す連携停止の背景だと特定した。運用側の要望を否定せず、連携で解く案として提案した
9 月に開けなかった定例を 2 件開催した。議題を期限のあるものだけに絞り、事前確認のページに判子を押してもらう形で合意を取った
担当イシューは月初 96 件から月中 134 件まで増えたが、月末に超過・着手遅れを 0 件にした

副業・個人プロジェクト #

副業プロダクトは配布 2 回、サーバー反映 6 回、マージした変更 41 本という最も密度の高い月だった
価格改定を 11 ステップの手順書に沿って無事故で完走させた。決済サービスの価格の作り直しから既存契約 36 件の移行、割引の再適用 20 件、公開ページ、プラグインの配布まで一度で通した
値下げの反映後 3 日で新規契約が 21 件集中し、月では正味で前期間を上回った。一方で解約した人の多くはほとんど使わずに離脱しており、値下げは新規には効くが解約には効かないという見立ては変わらなかった
公開サイトの断続的な停止は、告知で 10 倍のアクセスが来たことが引き金だった。上限が 2 段構造（有料プランに上げても旧モデルの制限が残る）だと気づいて解消し、CPU 超過を 806 件から 0 件にした
単品プランの購入で契約が保存されない障害を復旧させた。データベースの制約に新しいプラン名が入っておらず、約 5 時間半のあいだ購入者が利用できない状態だった
音声同期の失敗原因を「冒頭の無音」「時間切れ」と 2 回外したあと、本番同条件の再現で探索幅の不足だと確定させた
セキュリティ監査を 6 観点の並列調査で実施し、穴 7 件を洗い出して翌月以降のロードマップの軸に据えた
請求は契約どおりの全額ではなく、翌月から保守期間に入ることを踏まえて超過分を請求しない形にした。事前に伝えていた目安の範囲に収めた
自宅環境を一段整えた。ミニ PC をメイン機にしてエージェント履歴を 2 台で自動同期し、VPN のロック機能を署名ノード 3 台構成で有効化した
公開ノートを 3 本書いた（履歴の自動同期、自宅ネットワーク構成図、VPN のロック機能）
ノートの文体の基準を決めた。常体、太字をほぼ使わない、和文と欧文の間に半角スペースを入れる
デイリーノートを 31 日すべて記録できた（7 月は 9 日、8 月は 8 日、9 月は 23 日）

ゲーム実況 #

10 月も収録・編集・投稿の記録が 1 件も無い。8 月を最後に 2 ヶ月連続でゼロ、7 月から数えると 3 ヶ月ほとんど動いていない
登録者数も 7 月末の 143 人のまま記録していない
関連する動きとしては、レトロゲームのコレクション管理アプリの構想を再見積もりした。開発よりもデータの入手元と権利が最大のリスクという整理になった

健康・暮らし #

デイリーのプライベート欄は 31 日すべて空だった。体調・家族・食事・運動の記録が無い
日報の多くが「0 時すぎに」「未明に」から始まっている。副業の作業が深夜に寄り、本業の朝の定点観測と組み合わせて稼働の帯が広がりきった
合計稼働は 176.8 h で、8 月の 157.3 h を超えた
睡眠投資のフォーマット化は 5 ヶ月目の持ち越し

10月の総括 #

成果 #

休日のデータ連携点検を、並列調査・記録・定点観測の cron という形まで仕組み化した
構造的な不具合を 6 件直した（鮮度判定の時刻固定、起動本数の畳み込み、連打の間隔制御、暗号スイート、型の不一致、条件式の誤り）
外部メンテナンスによる 143 本の全滅を同日に全復旧させた
メモリ不足のジョブを恒久対応し、欠損 6 日分も回収した
通知の未達を解消し、受理数を倍増させた
秘密情報の露出を解消し、引き継ぎ権限まで整えた
脆弱性アラートを 480 件から 262 件へ減らした
クライアントのサーバー更新を障害から復旧させ、移行コストの見積もりまで出した
9 月に開けなかった定例を 2 件開催し、遅れを取り戻した
担当イシューの超過・着手遅れを 0 件にした
副業プロダクトで配布 2 回と価格改定を無事故で完走させ、値下げ後 3 日で新規 21 件の反応を取れた
公開サイトの断続停止を、上限の 2 段構造まで突き止めて解消した
自宅環境（メイン機の移行・履歴の自動同期・VPN のロック）を整え、公開ノートを 3 本書いた
デイリーノートを 31 日すべて記録した

課題 #

指標の目標値を「10 月末に確定」と置いていたのに、確定の記録が無い
7 ヶ月動いていなかった個人情報のハッシュ化は、発見しただけで着手の判断が残っている
新規 EC 連携の開発者登録を月内に出せなかった
認証情報の二重管理は提案までで、起票に至っていない
認証情報の未反映による停止が月内に 4 件。検知はできても構造は変わっていない
サーバー更新で 37 分の障害を出した。設定ファイルの扱いを事前に確認する手順を持てていなかった
動画が 3 ヶ月ほとんど止まっている
プライベート欄が 31 日すべて空。稼働 176.8 h は 8 月を超えた

学び #

点検は人を増やすのではなく、担当を分けて並列にするほうが速い。総括は 1 人でできる
「上限を上げる」で済ませると構造は残る。クォータは引き上げられても、連打している実装は変わらない
上限は 1 つではない。有料プランに上げても旧モデルの制限が残っていた。「上げたのに直らない」ときは別の層を疑う
原因の仮説は早く出して早く訂正したほうが進む。3 回目で正解に辿り着いた
認証情報の保管場所が 2 つあると、必ず片方が古くなる。運用側の要望を否定せず連携で解くほうが通る
通知が失敗数だけを数えていると、自然復旧後も鳴り続けてノイズとして無視される
バージョンの統一は 1 箇所では終わらない。CI・コンテナ・ビルド設定を横断で確認する
記録は仕組みに乗せれば埋まる。31 日書けたのは、前月に取り込み経路と作り方を直したからだった

所感 #

「見つける」から「構造を直す」へ移った月 #

9 月までは欠損を見つけて埋める作業が中心だったが、10 月は判定ロジック、起動本数、連打、暗号スイート、条件式と、構造そのものを直す案件が並んだ。どれも「毎日通知が出ているのに誰も根本を見ていない」類のもので、点検を仕組みにして手が空いたから着手できたという順序だった。本業の稼働が前月の 2 倍以上になったのは、この移行のコストでもある。

人力の点検を並列に置き換えられた #

休日点検を 11 担当の並列にして、自分は総括と判断だけをやる形にできた。改善・悪化・新規という粒度で差分を出せており、人力では追えない範囲をカバーしている。一方で、点検の責任範囲を決めたのは翌月頭で、10 月中は対象外のものまで拾って報告していた。範囲を決めるのが先だった。

一度壊してから手順を直した #

秘密情報まわりの適用で、確認を飛ばした結果デプロイを壊した。復旧まで 2 日かかった。手順書に注意書きを足して終わらせず、確認なしで通ってしまう権限の状態そのものを直す必要がある。

他人のミスを責める形にしない #

連携の停止がメンバーの手動操作に起因していた件では、事実と影響だけを出して共有し、本人が復旧を引き受ける形になった。判断の誤りそのものを責めず、誤判定の材料になった別件の存在まで添えて伝えたのが良かったと思う。

リリースの密度と障害の比率 #

副業プロダクトは配布 2 回と価格改定を無事故で通せた。多段のリリースは手順書を 1 本にまとめて順序を固定すると事故が出ない。一方で、稼働の内訳では障害対応と不具合修正が新機能を上回っており、利用者が増えた分だけ運用が重くなっている。翌月から保守が定額に入るので、再発を減らす側に時間を使う。

生活側が完全に記録から消えた #

プライベート欄が 31 日すべて空というのは、7 月から 9 月よりも悪い。仕事の記録は最も充実した月なのに、体調も家族のことも何も残っていない。深夜 0 時台から未明にかけての作業が日常になり、朝の定点観測も入るので稼働の帯が広がりきっている。176.8 h は 7 月に「持続しない」と書いたときより増えている。

動画は決める時期 #

3 ヶ月ほとんど動いておらず、登録者数も追っていない。「落ち着いたら戻す」という前提を 4 ヶ月続けているので、月 1 本の最低ラインを決めるか、年内はやらないと決めて心理的な負債を消すか、どちらかにする。

今後に向けて #

指標の目標値を確定させる（10 月末の予定が未達）
7 ヶ月動いていなかったハッシュ化処理の優先度を判断し、着手する
新規 EC 連携の開発者登録を出す
認証情報の二重管理を起票し、連携として進める
認証情報の未反映を早期に検知する仕組みを作る
確認なしで適用が通ってしまう権限の状態を直す
副業プロダクトのセキュリティ 6 件を進める
検証環境の決済が本番の権限になる問題をつなぎで塞ぐ
稼働の配分を戻す（深夜作業を前提にしない）
動画は「月 1 本の最低ライン」か「年内はやらない」のどちらかに決める
登録者数を月末に記録する
睡眠投資のフォーマットを 1 つ決める

📓 memotty