ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。(英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。) プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか? まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。
「cgi界」という言葉があるかどうかは知らないが、「Premature end of script headers」というエラーに対して、都市伝説というか民間療法というか、そういうのがあるようだ。例えば、 #! /usr/bin/perl 。。。。でこのエラーとなるときに、 #! /usr/bin/perl -- 。。。。とすれば「なぜかわからないが直る」(笑)と書いてある。 そもそも、このメッセージは、「cgiプログラムがContent-Type ヘッダを出力する前に終了した」ということを示すだけであって、ほとんどの場合、その前に本当のエラーメッセージが出ているはずだ。例えば、 (2)No such file or directory: exec of '/var/www/html/test.cgi' failed Premature end of script headers: tes
チラシの裏的な雑記です。 サービスに新しいデータストアを選ぶ際にこの辺を情熱を持って説明してくれる人が好き、という話です。 そのデータストアを使う理由はなんですか?みんなが使い慣れている物から変える理由は「有名な会社が使っていて^^」「他のチームが使っていて^^」とかではなくて、既存の物では解決出来ない問題を解決するアプローチになっていますか? もし単純にキャッチアップしておきたいというレベルなら、あなたの趣味で作るシステムで運用する、では欲求を満たせませんか? 同じようなプロダクトは他にもあると思いますが、そのプロダクトで無ければいけない理由はなんですか? まだ新しいプロダクトだった場合、あなたはそのコードを読んで、バグを報告して、必要であればパッチを書く覚悟を持っていますか? あなたはチーム内でそのプロダクトの第一人者になる、という覚悟がありますか?他のメンバーへの啓蒙や情報共有を率先
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く