スレッドIDを利用したMySQLのデッドロック解析手法
AWS, GCP, Azureの障害情報の提供方法とTwitterボット
AWS, GCP, Azureの障害情報の提供方法とTwitterボット 2016-10-24 Twitterボットを作るのが趣味という記事を以前書いたが、そのからみでAWS(Amazon Web Service)、GCP(Google Cloud Platform)、Microsoft Azureの主要3クラウドの障害情報Twitterボットを作った。面白いもので3サービスとも障害情報の提供方法やポリシーが違っていて、ボットのような障害情報を取ってきて通知する仕組みをつくるのはちょっと面倒。せっかくなのでボットの宣伝も兼ねて障害報告に関するサービス間の違いを挙げておく。自分で通知の仕組みを作ったり、サービスを選ぶときの参考に。 ちなみに、これらのサービスを既に使っている人は、単純にこれらのボットをフォローするか、Slack(英語の公式ドキュメント、日本語記事)やHipchat(Zapie
LinuxサーバでネットワークI/Oで刺さっている接続先を発見する - ゆううきメモ
Linuxサーバの障害対応で社内で伝統的に使われているテクニック。I/Oで完全にブロックしているポイントを特定するノウハウ。 問題対応のため、怪しいプロセスをstraceしてみる read(2)やwrite(2)でブロックしていることを発見する read(2)やwrite(2)、connect(2)の引数にはファイルディスクリプタ番号がみえる プロセスIDとファイルディスクリプタ番号を使って、/proc//fd/ の中身をみると、ソケットI/Oで刺さっている場合はソケット番号を発見できる netstat からソケット番号でgrepして接続先を発見する [y_uuki@hogehoge ~]$ sudo strace -p 10471 Process 10471 attached - interrupt to quit read(58, <unfinished ...> Process 10
チーム状態をスムーズに変えて障害対応のコストと精神的負荷を抑える - CARTA TECH BLOG
こんにちは。 @at_grandpa です。普段はバッチを書いたりメンテナンスをしています。 今回は、先日起きた障害対応の時、チームの状態をスムーズに変えることで対応コストと精神的負荷を抑えられた、ということを書きます。 目次 目次 障害発生 普段の対応 今回の対応 原因究明と現状把握 関係者が会議室に集まる 対応用Slackチャンネルを開設 ペアワークで実対応 落ち着いたら自席&Slackコミュニケーションへ移る 対応完了の確認と報告・チケットまとめ まとめ 障害発生 先日の朝に「レポートの数値がおかしい」という連絡がきて確認したところ、とあることが原因で、バッチの自動実行が約半日行われていないことがわかりました。 普段の対応 普段の対応は以下のような形です。 エラー発生をSlackの全体チャンネルで報告 バッチ系チャンネルにて、考えや現状を垂れ流す わからないことがあれば有識者にメンシ
「障害に捨てるところなし」というお話をしました - Cybozu Inside Out | サイボウズエンジニアのブログ
どうも！アプリケーション基盤チームの@yokotasoです。 3月11日にBattle Conference U30 というイベントでお話をさせていただきました。 準備がてら作成したディスクリプションを公開します。 キーノートはSpeakerDeckからどうぞ!こちらも参考にしていただければ、嬉しい限りです。 では、どうぞ！ 障害にすてるところなし サイボウズ株式会社の横田です。 「障害に捨てるところなし」というタイトルで少しお話させていただきます。お手柔らかによろしくお願いします。 運用障害の話 まずはじめに、今回のお話をするにあたりまして 運用障害でご迷惑をおかけしたみなさま、大変申し訳ありません。 より快適に利用いただけるサービスを目指しまして、対策・改善をおこなっております。 これからも、弊社製品をよろしくお願いいたします。 クラウドの規模と稼働率 障害の話をする前に、サイボウズの
GMO、先週の24時間にわたるサービス障害時にはデータセンター内の約12％が電源喪失。変圧分電盤故障が原因の可能性。監視体制の強化など対策
先週末、2016年1月16日から17日にかけて、GMOインターネットが提供するレンタルサーバやドメイン名登録などのサービスで管理画面が表示できなくなるなどの障害が約24時間にわたり発生しました。 GMOインターネットはWebサイトで影響の範囲や復旧状況などを報告、それによると障害の影響範囲は、お名前.com、レンサバ.comなどに加え、ConoHa byGMO、GMOアプリクラウドなどクラウドサービスまで広範囲に渡っています。 また、障害の原因は「データセンター内における電源設備の一部故障」とされました。 24時間という長時間かつ広範囲に発生した障害の実態はどうだったのか、また原因とされた電源設備の一部故障とはどのようなものだったのか、GMOインターネットの発表は詳細部分について触れられていなかったため、PublickeyではGMOインターネットに対して取材を申し込みました。 GMOインタ
障害対応でよくつかうコマンド覚書(逐次更新) - Qiita
はじめに よく障害対応の際につかうコマンドの見方を自分でまとめていたものを一般公開してみる。 詳細についてはここを参考にせずにちゃんとmanをよみましょう! w ヘッダ部 現在の時刻 Uptime(システムが稼働している期間) 現在ログインしているユーザーの数 過去1,5,15minでのシステムのロードアベレージ Uptimeが短いと再起動した。 また、ロードアベレージの1が高く5,14が低いなら直近、 全部が高いなら継続、 1が低く他が高いならすでに問題が解消した可能性が高い。 下部 USER :ユーザ名 TTY : FROM :アクセス元 LOGIN:ログイン時間 IDLE :アイドル(現在時間-最後にttyにアクセスした時間)している時間 JCPU :そのttyから実行されている全プロセスが使った時間。これには 過去のバックグラウンドジョブは含まれないが、現在実行しているバックグラウ
システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita
IT界隈でエンジニアしていると、よく出くわすのが障害対応です。できれば会いたくないという人が多いと思うんですが、僕はけっこう好きです。障害対応。どこに原因があるのか調査をして、バランス良くベターな対応をしたときの楽しさは、プログラミングとはまた違ったものがあります。探偵っぽい感じが面白いですよね。もちろん、障害が発生しない状況を作るのが一番です 弊社では数多くのWebサービス／アプリを運営しているので、過去様々な障害対応をしてきました。その際に、解決までどんな道筋を僕がたどるのかを振り返ってまとめてみました。これが大正解なんてことはなく、人や事象によって違うとは思いますが。 なお、障害検知手法とか、サーバのコマンドとか、コードのデバッグ手法とか、具体的なことは一切出てきません。手続きと思考プロセス的な話です。 障害対応フローチャート 一般的な感じだと思いますが、障害報告から対応完了までのフ
ニトリの通販サイト、6日ぶり再開 リニューアルに伴う不具合から復旧
リニューアルは、サイトのグローバル対応やレビュー機能の実装、店舗在庫の閲覧機能、配送との連携機能などを追加するもの。23日午前10時までに新機能の一部を実装し、テスト的に公開していたが、再び休止。午後6時ごろに再オープンした。 関連記事 年金機構の公式サイト、半月ぶりに再開 日本年金機構は、脆弱性が発見されたとして6月6日から閉鎖していた公式サイトを22日に再開させた。 ニトリ通販サイト、リニューアルで不具合 5日経っても再開できず ニトリの通販サイト「ニトリネット」でリニューアル作業時のプログラムエラーによる不具合が発生。5日経った22日現在も再開できていない。[update] 「ワコール」Webサイト改ざん、閲覧者にウイルス感染の恐れ 32サイト停止、サーバ移転へ ワコールは、同社公式サイトが不正アクセスで改ざんされたと発表した。現在サーバの移行作業を行っており、再開は4月下旬以降を予
Microsoft Azureが10時間を超える障害。原因はストレージの性能改善のバグと運用のミスとの報告
Microsoft Azureが10時間を超える障害。原因はストレージの性能改善のバグと運用のミスとの報告 マイクロソフトのクラウドサービス「Microsoft Azure」は、11月19日水曜日の午前10時前（日本時間）から午後8時45分の10時間を超える長時間、ストレージや仮想マシンなど多くのサービスでサービスの中断や性能低下などの障害を引き起こしていました。 その原因について、Microsoft Azureのブログのエントリ「Update on Azure Storage Service Interruption」（日本語訳「Azure Storage サービスのサービス中断について - Microsoft Azure Japan Team Blog (ブログ)」で報告されています。 この障害で影響があったのは、Azure Storage、StorSimple、Azure Backu
何でもデバッグできるようになるスキル - ワザノバ | wazanova
https://www.youtube.com/watch?v=VV7b7fs4VI8 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 パッケージ（apt, yum, gem等）レポジトリのホスティングサービスであるPackageCloudを開発している、James Golickの講演です。 パフォーマンスの高いハイクオリティなソフトウェアをデプロイしたければ、あらゆるレベルでバグ修正ができるようになること。 まず、エピソードとして紹介しているのが、友人の会社のサイトが落ちて、あいにく、その会社のエンジニアが出払ってしまっていて、どうにかしてほしいと助けを求められたときのこと。 ソースコードを見たことない。 システムの構成を知らない。 phpは詳しくない。 SSHでアクセスできる情報だけはある。 とい
誰も教えてくれなかったMySQLの障害解析方法 - Qiita
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです＞＜ 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
