記事一覧

コードは直せた。でも「これ、どうやって本番に出すんだっけ」。前任者の頭の中にしかなかったビルド・デプロイ手順を、本番サーバーに残った手がかりから逆算して復元し、検証環境で確かめて手順書にするまでを、一人運用の現場目線で5ステップに整理しました。

「数字が合わないんですけど」と言われて初めて、データの食い違いに気づく。そんな経験はありませんか。お客さまより先に気づけるように、件数や合計を突き合わせる小さなチェックを毎朝自動で回す方法を、一人運用の現場目線で整理しました。明日そのまま使えるチェックリスト付きです。

朝までに終わっていたバッチが、気づけば始業に食い込むようになった。「どこが遅いの？」と聞かれて答えられないのは、あなたの力不足ではありません。直す前に、どこで時間を使っているかを測る順番を、一人保守の目線で整理しました。

「もう作り直したほうが早いのでは」と思いながら、今日もパッチを当てている。レガシーシステムを直し続けるか作り直すかを、期限・壊れやすさ・人・業務との合い方・体力の5つの問いで整理し、「部分的に作り替える」という第三の道も含めて、一人運用の現場で判断して説明するまでの進め方をまとめました。

本番作業は無事に終わったのに、翌朝「昨夜、管理画面が使えなかったんだけど」と言われる。作業より、伝え方で疲れてしまう日がありますよね。社内の関係者へ作業予定を事前共有するときに書く5つの項目と、「予定・開始・完了」の3回で送る連絡テンプレート、宛先の決め方を、一人運用でもそのまま使える形で整理しました。

「特定のお客さんのデータだけエラーになる」。いちばん早いのは本番DBを丸ごと検証にコピーすること——でも、そこで手が止まるのは慎重さの表れです。バグの再現に要るのは本番データそのものではなく「バグを起こす形」。条件を言葉にする・必要な分だけ取り出す・置き換えてから持ち出す、の3ステップで、個人情報を持ち出さずに検証データを作る方法を整理しました。

本番の作業枠で、手順書の3行目から「あれ、このパスで合ってたっけ」と止まってしまう。それは準備不足ではなく、手順を一度も「通して」いないだけのことがほとんどです。リリース前のドライラン（リハーサル）を、読み合わせ・検証で通し・本番で空打ちの3段階に分けて、一人運用でも30分から始められる形に整理しました。明日そのまま使えるチェックリスト付きです。

毎晩動いているのに、何をしているのか誰も知らないバッチ。「止めていい？」と聞かれて答えに詰まるのは、あなたの調べ不足ではありません。いつ動き、何を読み、何を書き換えているのか。ソースを頭から読む前に、外側から動作を解読していく順番を、一人保守の目線で整理しました。

「あと少しで分かりそう」と思いながら、気づけば半日。不具合調査が長引くのは、腕が足りないからではなく「どこで立ち止まるか」を決めていないからです。調査に時間の枠（タイムボックス）をはめ、区切りで続ける・相談する・打ち切るを決めるための型を、一人保守の目線で整理しました。

「直しました」と報告したら「いや、そういうことじゃなくて」と返ってきた——あの瞬間の脱力感、つらいですよね。改修の手戻りは、腕の問題より「どうなったら完了か」を先に決めていないことから起きがちです。依頼者と完了の定義を合わせるための4つの確認と、そのまま使える「完了条件メモ」の書き方を、一人保守の現場目線で整理しました。

深夜2時、枕元のスマホが震えた。起きて対応するべきか、朝まで待っていいのか——一人運用だと、その判断まで自分ひとりで背負うことになります。アラートを開いてから5分で「動く／見張りつつ待つ／朝に回す」を決めるための4つの問いと、待つと決めたときに安心して眠るための段取りを、現場目線で一緒に整理しました。

ログを開いたら、知らないIPからのログイン失敗が延々と並んでいた。焦って全部を一度に塞ぎたくなりますが、まずは数えて、入口を絞り、回数を制限し、2つ目の鍵を足す順番で十分です。一人運用でも自分を締め出さずに進めるブルートフォース（総当たり）ログイン対策の基本を、確認コマンドとチェックリスト付きで整理しました。

深夜の作業枠、手順書の7番目で見たことのない出力が出た。「もう少しでいけそう」と「今夜はやめる」のあいだで迷うのは、止める線が決まっていないからです。リリースを中止（アボート）する判断基準を、着手前・作業中・引き返せない手前の3か所に分けて、一人運用でも当日迷わない形に整理しました。手順書に貼れる5行のテンプレートとチェックリスト付きです。

「何か質問ある？」と前任者に聞かれて、何を聞けばいいのか分からなかった——引き継ぎを受ける側は、そもそも「何を知らないか」が見えていません。前任者がまだいるうちに聞き出しておきたいことを、4つの軸の質問リストと聞き方のコツにまとめました。

引き継いだサーバーで ss を打ったら、知らないポートがずらりと並んでいた——閉じたいけれど、閉じて何かが止まるのも怖い。内側と外側の2方向から開いているポートを洗い出し、「確かめる→外から閉じる→止める」の順で、戻せる形のまま減らしていく手順をまとめました。

「検証では何度やっても再現しないのに、本番だけエラーになる」——。手元で再現しない不具合は、どこから疑えばいいのか迷いやすいものです。本番と検証の「違い」をデータ・設定・量とタイミング・外部とのつながりの4つに分け、ログで起きた瞬間をつかみ、動く行と動かない行を並べて差分を探す順番を、一人保守でも回せる形で整理しました。

「請求書の合計が1円合わない」「CSVの注文番号の末尾が0になっている」「ある日から登録だけエラーになる」——。数字のバグは小さく見えて、どこを疑えばいいのか迷いやすいものです。ずれの型を見分け、正しい値と並べ、入力から表示までのどこでずれたかを区切って追う順番を、一人保守でも回せる形で整理しました。

在庫がマイナスになった、同じ注文が2件入った、更新したはずの内容が消えた——。手元では何度試しても再現しないのに、忙しい時間帯にだけ起きる。そんなバグは「同時に動いたとき」に壊れているのかもしれません。症状の型、ログでの見つけ方、コードの探し方、検証環境での再現まで、一人運用でも回せる順番で整理しました。

改修を本番に出して「直りました」と返したのに、翌朝「まだ同じ症状です」と言われる——。それは腕のせいではなく、「直ったと言える条件」を決めないまま確かめていたからかもしれません。修正が本番に届いているか、依頼者と同じ条件で再現しないか、ログの数字は減ったかを、一人運用でも回せる順番で整理しました。

夜中に当てた緊急修正が、次のリリースでなぜか元に戻っている——。それは注意不足ではなく、「直した場所」と「次に出す場所」が別々になっているから起きることです。hotfixを本流（開発中のブランチ）へ取り込む手順と、リリース前に「本番にだけある変更」を見つける確認方法を、一人運用の流れに落として整理しました。