現場の仕事– category –

IDCFクラウドのランサムウェア被害では、一部ゾーンのデータは「利用者自身のバックアップからのみ復元できる」と案内されました。クラウド事業者と利用者の守備範囲を分ける責任共有モデルを、運用担当が明日確かめられる3つの点とあわせて整理します。

バックアップを取っているのに、ランサムウェアの被害から戻せないことがあります。攻撃者はバックアップも暗号化・破壊するからです。警察庁の資料と大学の被害報道をもとに、運用担当が確かめたい保管先の分け方と、復元の訓練のやり方を整理しました。

使っていない環境変数を消しただけで、本番環境が1か月半前のコードに戻った。2026年10月にZennで公開された事例をもとに、ignore_changesが「いまの値を守る設定」ではない理由と、planに出ない変更を作業後の確認で拾う方法を整理しました。

夜間バッチの監視が「エラーが出たら通知」だけになっていませんか。起動しなかった、途中で固まった、終わらなかった――エラーを出さない失敗は意外と多いものです。起動・生存・終了・復旧の4つの観点と、監視のしくみ自体が状態を変えてしまう落とし穴を整理しました。

Excelの手順書からコマンドをコピペして、打ち間違いや工程飛ばしにヒヤッとした経験はありませんか。国立情報学研究所(NII)のクラウド運用チームが2015年ごろから実践する「LC4RI」は、手順書そのものを実行でき、結果も同じ場所に残る運用のやり方です。しくみと、明日から真似できる工夫を整理しました。

エンジニア歴11年目の開発者が連休明けに本番DBを消してしまい、約1時間で復旧した体験談がZennに公開されました。障害やセキュリティ事故が起きた瞬間、1〜3年目の運用担当は何をすればいいのか。インシデント対応の流れと実例から、新人がやるべき初動5つを整理しました。

サーバのアクセスログには、毎日おびただしい数の404が並びます。ただ、本当に手遅れなのは404ではなく、/.env や /.git に200が返っている行のほうです。攻撃されている状態と、すでに中を取られた状態を、awkの集計で分ける手順をまとめました。

Design Docとは、実装前に不確実性を洗い出す設計文書です。優秀なエンジニアが必ず書く代替案・懸念点・未決定事項の3点と、A4一枚から始める書き方を新社会人エンジニア向けにやさしく解説します。