Reactioは、システム障害の対応に特化したインシデント管理ツールです。障害発生時に、電話とメールで一斉通知。その後、インシデント管理や対応履歴のタイムラインが残るので、障害報告書の作成に便利です。

Content-Length: 293089 | pFad | http://b.hatena.ne.jp/june29/operation/
Reactioは、システム障害の対応に特化したインシデント管理ツールです。障害発生時に、電話とメールで一斉通知。その後、インシデント管理や対応履歴のタイムラインが残るので、障害報告書の作成に便利です。
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
リリースしました https://github.com/Songmu/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per
おかげさまで大増員! 想定以上のお申込みをいただき、関係者一同うれしい悲鳴をあげております。ありがとうございます。 このたび 受け入れ可能人数を70名さまに 大幅増員いたしました(第二次増員も検討中です)。 あきらめていた方も、この機会にぜひご応募ください。また、都合が悪くなってしまったという方はキャンセル手続きを取っていただけると幸いです。 どうやってモチベーション維持してるの? をテーマに、自社サービスを抱える会社のCTOなどを迎えし お話を聞いたり気になっていることを質問したりしてみよう! 自社サービスを持ち運用担当してるエンジニアはもちろん、 自社サービスに興味があるエンジニアさんもよってらっしゃいみてらっしゃい! 自社サービスを抱え運用フェーズに移行していると新しい技術や挑戦をなかなかできない。 運用が忙しくて手が回らない。 毎日毎日同じことの繰り返し、生きている実感が沸かない。
Webオペレーション研修イントロダクション さて、7/6 からは新たにWebオペレーション研修が始まりました。 初日はイントロダクションとして、Webオペレーション研修やゴールや進め方についてお話させていただきました。 新卒の@orzupが研修のログを残してくれていますので、当人たちがどのように取り組んでいるのかを知るには以下をご覧ください。 WebオペレーションのVagrant編 ログ · Issue #29 · orzup/rails-tutorial Webオペレーション研修のゴール 「アプリが『動く』インフラを、ステップ・バイ・ステップで成長させる」ことをゴールとして、5つのステップを設けました。 Vagrant編・Nyah編(後述)、合わせて5つのステップ 各ステップの課題は以下のとおりです。 Vagrant編 Web開発研修で作成した Rails アプリを、Vagrant で動
2015年GMOペパボ新卒エンジニア研修、Webオペレーション研修イントロダクションの資料 * http://www.slideshare.net/hifumis/20150608-thetaoofpepaboengineer-49152106 * http://www.slideshare.net/hifumis/20150609-webdevelopmenttraining * http://www.slideshare.net/hifumis/20150706-weboperationtraining * http://blog.hifumi.info/2015/06/14/pepabo-engineer-training-2015/ * http://blog.hifumi.info/2015/07/20/pepabo-web-operation-training-2015/ Re
スクラムにあこがれて。 インフラで実践したチームビルディングそれはサバ天 from ume3_ カンバンをやってカイゼンをしたというお話です。 ここ1年ぐらいずーっとリーダーとして チームビルディングに勤しんでいた。 チームを強くするにはどうすればいいか? チームでわいわいやるにはどうすればいいか? 簡単な話、仕事ってどうやったら進むのか? それをつきつめていった結果、なぜか特異な結果が生まれた。 なんだこれは。 社内に共有したものをせっかくなのでこちらへ公開という流れです。 モザイク多いのは勘弁。 これでも、けっこう内容けずったのです。 やっていることは、ホワイトボードの前で付箋紙はってわいわいやっているだけ。 スライドでは説明不足ですが、サイクルがちゃんとあって ぐるぐる回すことでチームが加速化するのが狙い。 見える化の力を今も実感しています。 こういったフレームワークの活用からの発展
HerokuのNew Pricingが発表されて実質無料で使い続けることは難しくなりました。このブログも例外ではありません。 「どうせその時がきたら誰かがいい感じの移行先を見つけるだろう。」 「Herokuの大体サービスみたいのが出てくるだろう。」 と思ってましたがそういう気配があまり無い。 社内ツールは基本全部Heroku上に作ってるし(意図せずMicroserviceになってる)、数も沢山あるので頼れる移行先が見つかるまではHerokuにお金を払い、見つかったら移行。ずっと見つからない雰囲気であればDigitalOceanに全部を移行という感じかなと思っています。 できれば無料がいいし、Herokuみたいにgit pushしたらデプロイがいいなと思います(capistranoは糞ダルイ)。 DigitalOceanにHerokuっぽいツールを入れる? 皆さんはどうしようと思っている雰囲
仕事でそういう話をしていて、もやもやしたので考えを整理しておく。 リスクとコストを正しく評価する ヒューマンエラーをシステムや仕組みによって防ぐといっても、全てのエラーが起きないようにするのは、網羅性とコストの面から不可能ではないかと思う。 つまり、ヒューマンエラーのリスク(原因となる作業の頻度と発生した場合の影響)と、それを仕組み化するコスト(構築と維持)を正しく評価した上で、費用対効果のよいものから対応していくことになる。 このあたりは 自動化するときに考えること - HsbtDiary(2015-05-03) で述べられている考え方にも繋がる。 ただ、これとは少し違うポイントとして「普通はそういうことはやらない」とか「注意すればいい」という思考があると考えている。 仕組みでヒューマンを守る そういった考え方は、そっくりそのままそれを仕組み化すべき理由になる。 これらの思考はリスクとコ
1970年代からゲーム業界で活躍する大ベテランのゲームデザイナー、Greg Costikyan氏がGamasutraに寄稿した「Ethical Free-to-Play Game Design (And Why it Matters)」(倫理的な基本プレイ無料ゲームのデザインとなぜそれが重要なのか)について要約して紹介 スマートフォンの普及で、日本でも基本プレイ無料のゲームに触れる人は多くなっているが、こういった基本プレイ無料ゲームを長期的に成功させるためには倫理にかなったものでなければならないというのがGreg Costikyan氏の考え方だ 日本ではここ数年でソーシャルゲームの人気が爆発的に高まっており、この手の問題も様々な場所で見かけることがあるが、そこには倫理や道徳といった部分が必ずと言っていいほど関わっている。 また、あなたがプレイしている/プレイしていた基本プレイ無料のゲームは
公開: 2011年8月21日15時55分頃 こんなニュースが……「療養費支給額「3兆円」 都広域連合がケタ違いのミス (www.asahi.com)」。 東京都後期高齢者医療広域連合からはおわびの文書が出ていますね。 後期高齢者医療高額療養費支給決定通知書誤記載についてのお詫び (www.tokyo-ikiiki.net)後期高齢者医療高額療養費支給決定通知書の誤記載について (PDF) (www.tokyo-ikiiki.net)本来は「平成23年8月16日」「¥1,351」となるはずのものが、「平成23年80月16日」「¥3,510,000,000,000」となってしまったそうで。 その理由がちょっと驚きです。 同広域連合によると、通知書を作る際、職員がパソコン操作を誤った。支給額欄には13桁の数字を入れることになっているが、1351円を支給する場合も千の位の「1」の前にゼロを9個入力
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/june29/operation/
Alternative Proxies: