![Gmailへのメールが届かなくなる? 2024年6月までにやるべき3つの対応 | Web担当者Forum](https://cdn-ak-scissors.b.st-hatena.com/image/square/25b22c63567b918b06866bec0f85b7aae35281cb/height=288;version=1;width=512/https%3A%2F%2Fwebtan.impress.co.jp%2Fsites%2Fdefault%2Ffiles%2Fstyles%2F1200x630%2Fpublic%2Fimages%2Farticle2024%2Fgmail_wacul%2FWACUL_ogp.png%3Fitok%3D9L7EILJv)
どんなに対策をしていても、事故を完全に防ぎきることは難しい。大事なのはその後の対応である。2016年からスタートし、今年で8回目を迎えた「情報セキュリティ事故対応アワード」では、不幸にも事故に遭ってしまったものの、今後の模範となるような説明や情報開示を行った企業を毎年表彰している。本稿では、6月28日にライブ配信形式で開催された表彰式および審査員によるパネルディスカッションの様子の一部をレポートする。 主催:情報セキュリティ事故対応アワード実行委員会 後援:経済産業省 ロゴデザイン:カミジョウヒロ 審査員/パネルディスカッション登壇者 SBテクノロジー株式会社 プリンシパルセキュリティリサーチャー 辻 伸弘氏 EGセキュアソリューションズ株式会社 取締役 CTO/独立行政法人情報処理推進機構(IPA)非常勤研究員/技術士(情報工学部門) 徳丸 浩氏 NTTセキュリティ・ジャパン株式会社 コ
「 障害対応 」 エンジニアができるだけ見たくない単語ですね。 でも人間が作っているシステムである以上おそらく避けては通れない道... 実は直近で障害対応を経験し、正直すごくしんどい思いをしました。 今回はその教訓を記事に起こしたいと思います。 障害&起こったこと 2月某日クライアントから障害報告が来ました。 幸い既に障害原因箇所が今後は動かないコードの部分だったのでシステム自体の改修はありませんでした。 ですが、障害報告として対象データの洗い出しを行う必要がありました。 結構対象データの件数もあったのですが、粛々と対象しないといけないです。 一通り調査し、報告したところ トラブル発生 ... 調査結果に不備が見つかってしまいました。。。。 障害が起きている時点でクライアントは結構噴火寸前。 もちろん厳しいお言葉をいただきました。。。。 その後も続く調査&報告....そして厳しいお言葉の数
IaaS障害、ユーザー企業はどう対処すればいい? クラウドベンダーが教える対応法と振り返り(1/2 ページ) 天災や人的ミスなどで起きるIaaS障害。ユーザー企業にとっては防ぐのが難しい問題で、基本的に障害解消に向けてユーザー企業側でできることはほぼない。待つしかないのだ。 しかし、IaaS障害に端を発する自社サービスやシステムの障害はユーザー企業側でどうにかしなければならない。IaaS障害が発生してから復旧までの間やその後の対応など、ユーザー企業はどう行動すればいいのか。 今回はさくらインターネットでクラウド事業本部の副本部長を務める大久保修一氏に、IaaS障害発生時の対応方法を聞いた。重要なのは「事前の備え」と「事後の振り返り」だ。 特集:IaaSの冗長性確保 "金融機関や官公庁、政府までもが基幹系システムをクラウド環境に移行する“クラウドファースト”時代。しかし、近年はIaaSベンダ
はじめに こんにちは。webエンジニア社会人をしている ningenMe です。 タイトル通り。MySQLで3億レコード物理削除した話。 ちょっとハマったので備忘録。 はじまりはアラート はじまりはアラートだった。 僕が運用・保守しているバッチサーバでは、mysqlからちょうど直近1ヶ月分のデータを毎日1回selectする定期処理をしている。 いつもなら1時間程度で終わる処理のはずが、その日は7,8時間経っても終わらずアラートが鳴り止まない.....。 原因追求 とりあえずリトライしたり、ログ見たりしたもののあんまり悪いところがなかった。 クエリもちゃんとindex効いてる。なんでだろうと思ったらDBの容量が結構大きくなっていたことに気づいた。 3億5千レコード。インデックスちゃんと効いてたので多分普通に遅いだけっぽい。 必要なデータ取得は1ヶ月分である12'000'000件ほど。このse
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く