タグ

運用に関するnnnnnhisakunのブックマーク (10)

  • 【社内資料公開】構築担当者向け 運用チームに引き継ぐ時に気にしてほしい3つのポイント | DevelopersIO

    はじめに こんにちは植木和樹@上越妙高オフィスです。AWS上でのインフラ構築が終わり、アプリケーションがデプロイされるといよいよサービスローンチ。数日〜数週間様子をみて問題がなければ運用チームに業務を引き継ぐことが多いかと思います。 運用チームへの引き継ぎ資料を作って「あとはよろしくね」となるわけですが、その段階で「待て」がかかってしまうことがあります。(だいたい待てを言うのは私なんですが) 今回はスムーズに運用チームに業務引き継ぎができるように、私が注意しているポイントをまとめておきたいと思います。 3つのポイント 注意するポイントは3つです。 1. Input なにをトリガーに作業が始まるのか。どんな通知がくるのか。 2. Action 何をするのか。 3. Output 作業が終わったら誰に報告するのか。 1つずつ説明していきます。 1. Input 運用チームは基的に「イベント・

    【社内資料公開】構築担当者向け 運用チームに引き継ぐ時に気にしてほしい3つのポイント | DevelopersIO
  • Mackerelで始めるITインフラ監視 | こえむの編集後記

    Webアプリエンジニア養成読 Advent Calendar 2014 8日目の記事です。 今日は、に書ききれなかった内容についてです。 僕はWebアプリエンジニア養成読(以下 先のムック)にてITインフラの構築(3章)・運用(4章)を担当しました。この中で、監視方針と閾値設計について説明したのですが、紙面の都合で監視サーバ・システムの構築にはあまり触れることはできませんでした。そこで、今回は実際に監視システムの構築について、「なぜ Mackerel か」「Mackerel 設定の流れ」そして「設定が終わったら」にまとめてお話しします。 お手許に先のムックがある方は、ぜひご用意ください。の内容に沿って説明します。 なお、執筆時点での状況を記します。今後、状況が変わる場合がある事を念頭にご覧下さい。また、OSはRHEL, CentOS 6系である事を前提とします。 2015/01/1

  • クラウド専業CIerがAWS監視運用でZabbixを使う理由 - サーバーワークスエンジニアブログ

    CloudWatchがあればZabbixとできること大して変わらないし 「CloudWatchでだいたいの要件は満たせそうですね。」 とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。 統合監視ができる CloudWatchはあくまでもAWSの中の事象だけを見ます。 しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、 クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。 そういった場合すべてを統合的に見られる監視ツールが必要となります。 またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。 たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを

    クラウド専業CIerがAWS監視運用でZabbixを使う理由 - サーバーワークスエンジニアブログ
  • %E8%87%AA%E5%AE%85%E3%81%A7%E5%A4%A7%E5%AE%B9%E9%87%8F%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B8%E3%82%92%E9%81%8B%E7%94%A8%E3%81%99%E3%82%8B

    前回 RAID に関するちょっとした話を書きましたが個人が巨大なストレージを運用するにあたって得られたノウハウをだいたい全部書いておきます。 そもそもメリットあるのか? メリットはあります。金です。 Google Drive は安いですが、それでも 1TB 月 1000 円です。しかし運用にかなり制限がでます。柔軟に使える Amazon Web Service ならその 3 倍+転送量課金です。 16TB だと月 5 万円もかかってしまいます。ちなみにもっとも柔軟に使える EBS だと 16TB で 83000 円ぐらいです。 Google Compute Engine の低冗長性ストレージは S3 より少し安かった気はするけど別にとても安いわけではなかったと思う(よく覚えていないし調べるのがめんどくさい)。 50TB のストレージを Google Drive でごまかしごまかし運用したと

  • Facebookの数千台規模のmemcached運用について - ゆううきブログ

    Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログの続きとして、Facebook の memcached 運用に関する論文を読んだ。 タイトルなどは以下の通り。 NSDI はネットワークシステムに関するトップレベルのカンファレンス。 Scaling Memcache at Facebook Rajesh Nishtala, Hans Fugal, Steven Grimm, Marc Kwiatkowski, Herman Lee, Harry C. Li, Ryan McElroy, Mike Paleczny, Daniel Peek, Paul Saab, David Stafford, Tony Tung, Venkateshwaran Venkataramani NSDI'13 In Proceedings of the

    Facebookの数千台規模のmemcached運用について - ゆううきブログ
  • Engadget | Technology News & Reviews

    Pick up the 9th-gen iPad with two years of AppleCare+ for only $298

    Engadget | Technology News & Reviews
    nnnnnhisakun
    nnnnnhisakun 2014/01/24
    「武装集団が入ってきた場合に対応できるかというと。。。」<最近ISMSのヒアリング時に聞かれるらしいですねぇ。「トラックや飛行機が突っ込んできても物理セキュリティが破られる事は無いの?」とか。
  • 「モバゲータウン」のつくりかた − TechTargetジャパン システム開発

    低価格なPCサーバ1000台で1日6億PVをさばく 「モバゲータウン」(以下、モバゲー)といえば、誰しも「中高生に絶大な人気を誇る携帯サイト」という認識ぐらいはあるだろう。ゲーム、ニュースに小説占いなどのコンテンツ、アバター(仮想キャラクター)を装ったSNSコミュニケーション、ディー・エヌ・エー(以下、DeNA)が運営するショッピングやオークションサイトなどが利用できる、携帯電話向けの総合ポータルサイトだ。 DeNAのポータル事業部 システム部 部長、武部氏 モバゲーは2009年5月現在で会員数1419万人、月間ページビュー(PV)は約183億を誇る。つまり、1日当たり6億PVである。さぞかし大掛かりなシステムを運用しているのだろうと想像してしまうが、意外にそうではない。 DeNAポータル事業部 システム部の部長、武部雄一氏は「モバゲーのシステムは、比較的低価格なPCサーバ機1000

    「モバゲータウン」のつくりかた − TechTargetジャパン システム開発
  • 知らなきゃ損するiptablesのTips

    はじめに 最終回にあたり、iptablesを便利に使うTipsを紹介します。iptablesを1つ1つコマンドラインで実行するのは大変面倒です。そうした煩わしさを軽減できる設定や、実際の運用の手助けになるような工夫を紹介します。 関連リンク: →Linuxで作るファイアウォール[パケットフィルタリング設定編]http://www.atmarkit.co.jp/flinux/rensai/security05/security05a.html →連載記事 「習うより慣れろ! iptablesテンプレート集」http://www.atmarkit.co.jp/flinux/index/indexfiles/iptablesindex.html →連載記事 「習うより慣れろ! iptablesテンプレート集 改訂版」http://www.atmarkit.co.jp/flinux/index/i

    知らなきゃ損するiptablesのTips
  • Linuxで自宅サーバ構築・管理: KSKNET

    stat - ファイル情報の取得 stat関数はファイルの様々な情報を得るための関数です。この関数を使うことでファイルサイズや、ファイル所有者、最終更新時間などを調べることができます。

  • レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ

    MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台+1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う!」「ここがおかしい!」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基構成、方針 2台+1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ

    レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - (ひ)メモ
  • 1