01ポートフォリオ

森川晴海

Platform / Backend Engineer · 日本在住

書いていることは、自分で動かしているものだ。

知っていることを並べるのは在庫だ。計測したこと——そして間違えたこと——を見せるのが証拠だ。真似しにくいのは後者だけなので、このサイトは後者を残す。判断の裏にある数字、擁護せずに撤去した修正、そして自分で書いたその日の午後に自分で飛ばした手順。

代表プロジェクトを下に掲載

02仕事の進め方

観測し、Plan を作り、変更し、証明し、残し、もう一度観測する。うまくいかなかった部分も含め、運用の中から抽出した一つのループ。

緑しか出したことのない検査は、まだ何も証明していない。

状態条件が示すのは、制御器が最後に行ったことであって、知りたい性質ではない。

実装の前に診断を記録する。作業より先にセッションが終わることがある。

033 つの事例

規模ではなく、何を証明しているかで選んだ 3 つ。それぞれが 1 つの主張と、その根拠と、そこから下した判断を持つ。

Camunda アップグレード

接続ポリシー：調整の前に計測する

主張: 効いているように見える修正が、悪化させている当人であることがある。見分ける方法は計測しかない。
根拠: Envoy の /clusters 統計そのもの——「修正済み」のサービスは 778 リクエストを捌くのに 697 本の接続を開いていた。変更から外した比較対象は通常どおり再利用し、182 に対して 88 本。
判断: 再調整ではなく完全に撤去し、判断根拠を記録に残した——黙って戻ってこないように。

実行証拠まで含めた GitOps 配信

主張: main への push がそのままデプロイになる。アプリケーションは自分のリポジトリから自ら登録し、退役も同じ経路で行う。
根拠: 2 つのガードレールが緑だったのは、どちらも赤くなりようがなかったから——壊れている当の import を解決しない検証と、自動コミットが既に置き換えた後の「最新のパイプライン」を見ていたデプロイ確認。
判断: 「異常なし」を信じる前に、同じ検査で何かが返ることを先に確かめる。走らせられなかった検査は、合格した検査と見分けがつかない。

運用者による復旧経路を持たない設計

主張: 私的な記録は、認証モデルが成立して初めて私的でいられる。そのモデルが壊れるのは、たいてい復旧の経路だ。
根拠: メールサーバーがなければ再設定の経路はなく、パスワードを忘れた時点で最も私的なデータが永久に失われる。かといって一般的な再設定フローは、守るべきデータへの最短の侵入口になる。
判断: 復旧は本人が自分で書く二つ目の秘密に依拠する。答えはハッシュとしてのみ存在し、運用者がアカウントを復元することはできない——私を含めて。

04公開中のプロダクト