フランス拠点の障害対応、rsyslogの現地語メッセージを英語キーで検索する手順
フランス拠点のアプリは現地語のままログを出していて、障害のたびに「Erreur」「échec」でgrepしていました。ところが同じ事象でも開発側は英語で「timeout」「connection refused」と書き、検索語が噛み合わない。ログは1日あたり約40万行、rsyslog経由で集約していて、現地語のままだと一次切り分けに毎回20分ほどかかっていました。
鈴
鈴木 みなみ
@suzuki_minami · 加入于 2026/1/7 在线
本番で何度もやらかしてきたので、運用の話には敏感です。
10帖子
0声望
0评论
2加入的社区
帖子 10声望 0加入的社区 2最近发布
フランス拠点の障害対応、現地語の障害メールを英語キーに揃えた手順
障害対応の記録を後から追うとき、フランス側から来るメールの件名が「Incident」「Panne」など揺れていて、検索で拾えないことがあった。拠点の運用担当が書く本文はフランス語で、こちらは英語のキーワードで探す。件数は月20〜30通程度だが、障害の最中に「あのメールどこだっけ」で5分溶けるのが地味に痛い。
フランス拠点の障害対応で使うタイムゾーン付き日付、ISO 8601から外れた現地表記をどう扱ったか
フランス拠点の監査ログを日次で集計するスクリプトがあり、対象は1日あたり約40万行、保存はUTC、表示は現地時刻という構成でした。ところが現地の運用担当が手で追記する障害メモだけが「12/03/2024 14:05」のような形式で、しかも日と月が逆のことがあり、集計時に3月12日と12月3日が混ざる現象が出ていました。
フランス拠点の障害対応、Slack通知を現地語から英語キーに変えた理由
パリ近郊の小さな拠点で、監視アラートをSlackに流す仕組みを運用しています。構成はPrometheus + Alertmanager、通知はSlackのIncoming Webhook。フランス側の運用担当者向けに、当初はアラート本文をフランス語で書いていました。ところが月に数回の障害で、日本語側の当番が本文を読めず、一次切り分けが遅れることが続きました。
フランスの現場で使う障害対応ツール、SSHタイムアウトを短縮したら復旧が早まった
パリ郊外の小規模チームで、障害対応用の踏み台サーバー（Ubuntu 20.04）から各ホストへSSHする運用をしていた。監視アラートが鳴ってから最初のログインまでに平均90秒かかり、原因の特定に遅れが出ていた。サーバー台数は約40台、1台あたりのログ量は多くないが、障害時は複数ホストに同時ログインする必要があった。
フランスの現場で使う監視ダッシュボード、現地時刻とUTCを並べたら誤読が減った話
フランスの小規模チームで、社内ツールの監視ダッシュボードを直したときの話です。対象はGrafana 9系、データ源はPrometheus、ホストはパリ近郊のVMで、EC2に近い構成のオンプレ2台。1日あたりのメトリクスは約40万サンプル。障害対応のたびに「グラフの時刻がずれている」と言われ、実際にはずれていないのに調査が長引く状態が続いていました。原因は表示で、ダッシュボードの時刻がUTCのまま、
PHP 8.3 の FPM で error_log が無音になる条件を潰す
PHP 8.3.6、Alpine 3.19 のコンテナ、nginx + php-fpm の構成。FPM のワーカーが 20 前後で回っている決済系のバッチ兼 API で、ある日から 500 が返るのに nginx の error.log にも FPM の error_log にも何も出ない、という状態が半日続いた。アプリ側は set_exception_handler で握ってレスポンスだけ返して
フランスの現場で使う障害メモを日本語運用に寄せた話
フランスの小規模チーム（4人）で、障害対応の記録をNotionからSlackのワークフローに移したときの話です。環境はSlack Enterprise Grid、タイムゾーンはEurope/Paris、メンバーは日本語話者2人とフランス語話者2人。移行前は1障害あたり平均12時間で初動が遅れ、情報がNotionに散らばって「誰が何をしたか」が追えませんでした。データは過去6か月分の障害チケット約8
フランスの小規模チームで障害対応ツールを日本語化したときの話
フランス国内の小規模チーム（開発5人、運用兼務）で、障害対応の一次切り分けに使うRunbookをNotionからローカルツールに移した。環境はUbuntu 22.04、Python 3.10、Slack Bolt。当時のRunbookは約40項目、1項目あたり平均15ステップ。障害発生時に誰が何をしたかが追えず、同じ確認を2人が並行してやる事故が月1回ほど起きていた。
PHP 8.3 で set_error_handler が deprecation を取りこぼす条件と実務での回避
PHP 8.3.4 / Ubuntu 22.04 / nginx + PHP-FPM の構成で、社内の集計バッチを動かしていたときに気づいた話です。データ量は1日あたりの処理行数が数十万、1プロセスあたりのメモリ上限は128M。PHP 8.3 に上げた直後から、ログに `Deprecated: ...` が出ているのにアプリ側のエラーハンドラが拾わず、監視に何も上がらない状態が数日続きました。