今日から業務で使える17の運用系Linuxツール、そして円環の理運用系ツールのつもりが、新人さんに伝えたい「円環の理」資料になってしまいました。 “qpstudy 2013.04”の @zembutsu LT 発表資料です 『qpstudy３周年記念LT大会 〜新人さん、業界にようこそ！〜 with ビール』 http://www.zusaar.com/event/613004� 共有したかった事 ・2013年、這い寄る混沌・ガラケーは衰退しました ・基本コマンドの連携は必須 ・時系列リソース監視が鍵 ・仲間達と協力する心も大切
全日空、10万超の座席指定を取り消し、原因は担当者の操作ミス
全日本空輸は2012年11月28日、予約システムの誤設定により、2013年2月の国内線を予約した顧客の座席指定を取り消したと発表した。11月26日午後6時までに購入された2013年2月搭乗分の国内線航空券の約10万6000席が取り消し対象となる。航空券の予約は無効になっていないが、座席指定の予約だけが取り消されたという。 原因は営業担当者の操作ミス。営業担当者が11月26日に時刻表の情報を予約システムへ更新する際に発生した。営業担当者が誤って座席指定の予約情報を消去してしまったという。「担当者が操作手順を守らなかったことが原因」（広報）としている。営業担当者2人によるWチェックを行ったが防げなかった。「今後管理職も加わって確認する手順に変える。担当者に対しても手順の遵守を徹底する」（同）としている。 対象者は同社のWebサイトや特設のコールセンターで改めて座席を指定する必要があるという。
ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認
ヤフー子会社のファーストサーバは2012年7月31日、6月20日に発生した大規模障害（関連記事）についての調査報告書（最終報告書）を公表した（写真）。報告書は、ファーストサーバに利害関係のない3人の委員による「第三者調査委員会」（関連記事）が作成した。同社Webサイトに「要約版」を掲載している。 報告書は調査対象とする事故を、6月20日に発生した「第1事故」と、第1事故で消失したデータが想定外の場所に復元された「第2事故」（関連記事）の2つとしている。 1人だけ自作プログラムでメンテナンス 報告書は、第1事故の事実関係について次のように言及している。ファーストサーバではシステム変更を実行する際、社内マニュアルに沿って実行することになっており、第1事故の原因となったシステム変更の担当者（A氏）以外は社内マニュアルに従っていた。 ところが、A氏だけはマニュアルに従わず、自作の「更新プログラム」
DC構築するときにラック内で電源を冗長化してUPS入れておいたら
なんか、あったなー。 DC構築するときにラック内で電源を冗長化してUPS 入れておいたら DCの人にデーターセンターレベルで電源が冗長化されているので、停電はありまえん。不要ですとかいわれて。 社内のエンジニアに割と白い目で見られたんだよね・・・ １か月後に、DCの設備点検で冗長化電源の切り替えテストに見事不具合が出て ワンフロアまるごと停電してたけど。 うん、２重化どころか多重化している。ガチ系サービスのデーターセンターを構築している人（設備の建物ごと）が、当たり前にラック内やってたから それを見て育っているから 万が一のことは起き得る。って見習ったんだよね。 でも、そういうのって 嗤われるんだ。この国だと。たまたま証明されたけど そうじゃなきゃ、笑いものだったんだぜ。 先輩がいるって重要だよな ってはなしと 迷信だと思っても理由を考えて真似をすることは重要だと思うよ。 そして、１００％
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
うちの会社のサーバー監視方法がおかしいので改善を試みた
前回の書き込み http://anond.hatelabo.jp/20120407162253どんな監視方法なのかをを簡単にまとめてみるうちの会社のサーバー監視方法１５台くらいのwindowsサーバーに自PCからリモートデスクトップ接続する遠隔操作でイベントログやらHDD容量やらを目視チェックして全て台帳（紙媒体）に書き込む以上を全サーバーに行うと普通に毎朝１時間かかる。負荷がでかいので分散の為、若手を入れて１０人くらいで順番にまわしている今後もサーバーが増える予定あり前回の書き込みの反応は大体以下のような感じだった頭おかしいｗｗｗ受けるｗｗｗｗｗいろいろ予想以上 これらのコメントのおかげで、おかしいのは自分の気のせいではないという事にようやく自信を持てた。とりあえず前回すぐにでもできそうな方法を方法を教えてもらったので改善できるかサーバー管理してるチームの一人に相談してみた。自分「毎朝
開発と運用の新しい関係、「DevOps」とは何か？ － Publickey
このところ海外のIT系の記事で「DevOps」という言葉を見る機会が増えてきました。スペルからすると、開発＝Developmentと、運用＝Operationを組み合わせた言葉らしい、という程度の認識でしたが、どうやらアジャイル開発やソフトウェアの品質にかかわる新たなムーブメントとして認識しなければならないかも、と感じはじめています。 そこで「DevOps」とは何か？ について調べてみました。 DevOpsとは開発と運用が協力し、ビジネスリスクを軽減する まずはWikipediaの「DevOps」の項目から冒頭の部分を読んでみましょう（2011年3月8日現在の記述）。 DevOps is a set of processes, methods and systems for communication, collaboration and integration between depar
Use Appcelerator Titanium to build mobile apps for iPhone & Android and desktop apps for Windows, Mac OS X & Linux from Web technologies
The Appcelerator offering has been discontinued All private source code of the Titanium SDK will be made public in the open source Titanium SDK github repository by March 1, 2022. For more information about the changes to Appcelerator, please read the full announcement and how to prepare your apps for Appcelerator end of support.
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
米Yahoo!がシステムダウンしない5つの理由
昨年の10月14日、米Yahoo!のトップページがダウンしたと、米Huffington Postが記事「Yahoo DOWN: Yahoo.com Outage Reported」で伝えました。米Yahoo!にとってトップページがダウンすることはきわめてまれなことで、この件が発生するまでほぼ10年にわたりトップページのダウンは起きていなかったと言われています。 その米Yahoo!はシステムダウンを防ぐためにどのような取り組みをしているのか？ 米オライリーが主催したイベント「Velocity 2011」で、Yahoo!サービスエンジニアリング部門のVice President、Jake Loomisが行ったセッション「Why the Yahoo FrontPage Went Down and Why It Didn't Go Down For up to a Decade before Th
私家版省サーバ運用2011またはWebシステムのコンポーネントの配置について - blog.nomadscafe.jp
小規模のサービスを如何にスモールスタートするか、そのために各コンポーネントをどうやって配置するのがいいのかという話。個人的な考えも含めて。 大まかな構成は昨年のnekokakさんのYAPC::Asiaでの発表、省サーバ運用と大体同じです。Web/Appに使うサーバ2台、データベース2台です。あとはLBが別にあればそれを、なかったらもう一台(組)必要となります。 Web/Appサーバには、Reverse Proxy、Application Serverがまず配置されます。あとは必要に応じてmemcached、Job Queueのworkerを動かします。ここまでのコンポーネントは2台のサーバ両方に配置し、Active-Activeで動作し冗長性がとれるよう構築します。cronについては、両方のサーバで動かしても問題がない状態が理想ですが、そうでない場合、Web/Appの1台目で動かすというル
BackupライブラリでプロジェクトのバックアップもD.R.Y化しよう
はじめに こんにちは芳賀@func09です。 何かプロジェクトをリリースする時、必ずといっていいほど必要なのはデータの定期バックアップですね。 必ずといっていいほど必要なのに、必ずといっていいほど忘れがちで、後回しにされがちで、 リリース前に「あ、バックアップのバッチ処理書かなきゃ・・」みたいな感じで、毎回同じようなシェルスクリプトを書いてませんか？僕はそんな感じです。 バックアップだってD.R.Y（Don’t repeat yourself）ということで、サクっと労力をかけずに終わらせたいなぁと思っていた時に見つけたのがBackupという名前のGemです。そのまんまですね。 Backup(RubyGem)とは？ Backup（ http://github.com/meskyanichi/backup ）はRubyで書かれたUnixとRails環境のためのライブラリです。 データベースの内
＠IT Special PR：PV急増で美人時計がさくらインターネットと組んだワケ
美人？ 好み？ そうでもない？ 見る人によってビミョーに意見が分かれつつも、つい見入ってしまう、いやし系のカワイイ女性たち。そんな“美人”たちが「18：43」などと時刻を大書きしたボードを手にした写真が次々に画面を彩る、話題のサービス「美人時計」。美人時計はどうやって生まれたのか、人気のヒミツと現場の苦労を中の人に聞いてみた！ 「広告を作る人も見ている人も、みんなが楽しめる、今までになかったものを作りたかった」。こう語るのは株式会社美人時計取締役でプロデューサーの中屋優大氏だ。新しい広告表現を模索するにあたって最初に目指したものは、広告を見る人も喜んで見続けるようなもの。そのためにアナログとデジタルの融合や、時間による変化を取り入れた「4次元広告サイト」という新しいビジネスモデルを模索したという。 「便利で高度な機械に対しても、ぼくは人の温もりや癒しを求めてしまいます。同じような感覚を持っ
「モバゲータウン」のつくりかた − TechTargetジャパン システム開発
低価格なPCサーバ1000台で1日6億PVをさばく 「モバゲータウン」（以下、モバゲー）といえば、誰しも「中高生に絶大な人気を誇る携帯サイト」という認識ぐらいはあるだろう。ゲーム、ニュースに小説、占いなどのコンテンツ、アバター（仮想キャラクター）を装ったSNSコミュニケーション、ディー・エヌ・エー（以下、DeNA）が運営するショッピングやオークションサイトなどが利用できる、携帯電話向けの総合ポータルサイトだ。 DeNAのポータル事業本部 システム部 部長、武部氏 モバゲーは2009年5月現在で会員数1419万人、月間ページビュー（PV）は約183億を誇る。つまり、1日当たり6億PVである。さぞかし大掛かりなシステムを運用しているのだろうと想像してしまうが、意外にそうではない。 DeNAポータル事業本部 システム部の部長、武部雄一氏は「モバゲーのシステムは、比較的低価格なPCサーバ機1000
Yahoo!ショッピングにおけるログ設計と監視
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ショッピング事業部開発部の吉野と申します。 今回は「アプリケーションログの設計と監視」について、実際にYahoo!ショッピングで採用している方法を少し交えながらお話しさせていただきます。 1.ログ設計のポイント ログ設計は、以下のポイントに注意して行うとよいでしょう。 ・ログ出力のポイントが押さえられているか ⇒セッションの始まりと終わり、処理の過程、例外処理の中など。 フローチャートのような処理フロー図があれば、そこにログ出力ポイントを書き込むとわかりやすくなります。 ・出力する情報に過不足はないか ⇒「いつ(システム時間)」「だれが(プロセスID・IPアドレスなど)」 「どこで(パスなど)」「なにをした(実行コマン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
cloudpackブログ - EC2の障害復旧パターン
ノリブログ?-mysqlクエリとCPU状況をシェルスクリプトで監視
あなたのWebサーバのログの保存ポリシー、logrotateのスクリプト or 参考にしているURL等を教えて下さい。…
Server Fault
