Enterprise Roadmap to SRE - Google - Site Reliability Engineering
Google が過去に出版した 2 冊の書籍「Site Reliability Engineering」と「The Site Reliability Workbook」は、サービスライフサイクル全体への取り組みによって、組織がソフトウェアシステムの構築、展開、監視、保守を成功させる方法と理由を示しています。本レポートでは、Google Cloud Reliability Advocate の Steve McGhee と Google Cloud Solutions Architect の James Brookbank が、組織で SRE を導入する際にエンジニアが直面する特定の課題について深く掘り下げています。 SRE の普及にもかかわらず、多くの企業では SRE に対する当初の熱意と、その採用の度合いの間に大きな隔たりが生じています。本レポートは、プロダクトオーナーや信頼性の高いサー
システム運用アンチパターン
上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。 重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。 組織で必要とされる変化を、エンジニアが行動することで実現する本書は、ソフトウェアシステムをよりよく開発運用したいエンジニア必携の一冊です。 目 次 序文 本書について 1章 DevOpsを構成するもの 1.1
入門監視やSRE本に学ぶ障害対応フォーメーション - An Epicurean
システム障害が起こったときにどういう体制で望むか、エンジニア個人が障害に直面した時にどのような役割を受け持つのが良いのか。組織によって色々なパターンはあるでしょう。しかし、幸いにも「入門 監視」やSRE本に書かれている4つの役割分担が浸透しているので、それをベースに考えるのがファーストステップとしては良いのではないでしょうか。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム オライリージャパンAmazon ただ、小さな組織では障害時に4人もすぐに揃わない場合もあるでしょうし、そもそも4人もスタッフがいない、と言う場合もあるでしょう。そういった場合にもどうすればいいのか考えていきます。 役割分担の基本 「入門 監視」に
Public Suffix List の用途と今起こっている問題について | blog.jxck.io
Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ
無料＆オープンソースでシステム障害のレポートを一元化できるNetflix製インシデント管理ツール「Dispatch」
システムの保守・運用を行うインフラエンジニアにとって、障害対応は最も責任のある仕事のひとつであり、障害の監視や通知に関するツールは「PagerDuty」や「Zabbix」が有名です。そうした障害対応を助けてくれるツールとして、Netflixが無料のオープンソースソフトウェア「Dispatch」を公開しました。 Introducing Dispatch - Netflix TechBlog https://netflixtechblog.com/introducing-dispatch-da4b8a2a8072 About - Dispatch https://hawkins.gitbook.io/dispatch/ Netflix Dispatch - Reviews, Pros & Cons | Companies using Netflix Dispatch https://stack
TechCrunch | Startup and Technology News
There has been a silly amount of drama in the run-up to Tesla‘s annual shareholder meeting on Thursday. The company is set to hold a vote on “re-ratifying” the $56…
伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する（前編）。QCon Tokyo 2016
クラウド上でアプリケーションを構築する新しい手法として「サーバーレスアーキテクチャ」が急速に注目を集めています。しかし一方で、サーバーレスアーキテクチャを採用することで得られる本質的なメリットはなにか、そもそもサーバーレスアーキテクチャとはなにを指すのか、などについてはまだ識者の間でも議論されていることです。 10月24日に都内で開催されたイベント「QCon Tokyo 2016」の伊藤直也氏のセッション「Serverless Architecture」は、こうしたサーバーレスアーキテクチャの本質について大きな示唆をもたらす内容でした。この記事では、その内容をダイジェストで紹介します。 （本記事は前編、中編、後編に分かれています。いまお読みの記事は前編です。） Serverless Architecture 一休 CTO 伊藤直也氏。 先に結論を言ってしまうと、サーバーレスアーキテクチャと
DeNAにおけるOpenStack運用#1 | BLOG - DeNA Engineering
DeNAでシステムインフラを運用しています小野です。 今回から3回に渡って、OpenStackの運用についてご紹介したいと思います。 OpenStackとは OpenStack とは、いわゆるクラウド環境を構築/運用管理するためのOSS platformです。2010年にRack Space社とNASAのjoint projectとして始まり現在ではOpenStack Foundationが管理しています。 OpenStackは多数のOSSで構成されています。mysqlやrabbitmqなどお馴染みのOSSもbackendに使われていますが、OpenStack固有のOSSが主要コンポーネントになっています。例えばcomputing(vmやcontainer)の管理をするnova、ネットワークを管理するneutron、WebUIを管理するhorizonなどなどです。 こちら でどういったコン
AWS の DNS フェイルオーバーで、サーバレス＆高可用性 Sorry ページを構築する
こんにちは、インフラストラクチャー部の沼沢です。 AWS の DNS フェイルオーバーの設定についての記事はたくさん出回っていますが、今回は Sorry ページに特化した設定をご紹介します。 以前、社内で AWS 上にシステム構築していた際に、例えば「急激なアクセス増で AutoScaling が間に合わないなどでユーザのリクエストに対して正常に応答できない状態に陥ってしまった時に “画面が真っ白な状態が続くこと” だけは避けたい」という要望を受け、最終手段的な位置付けで構築した Sorry ページ表示の仕組みについてご紹介させていただきます。 特段目新しい技術や情報ではありませんが、AWS にてサーバレスで高可用性な Sorry ページを構築する方法の参考になればと思います。 DNSフェイルオーバーとは？そもそも、DNS フェイルオーバーとはなんなのかを軽くご説明させていただきます。 ※
Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認（w） サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認（df） 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
インフラエンジニアの責任範囲と評価 - クックパッド開発者ブログ
インフラストラクチャー部の成田です。2015年10月現在、インフラストラクチャー部には私を含め7人のインフラエンジニアが所属しており、このメンバーでクックパッド本体サービスをはじめ様々な新規事業やいくつかの子会社のサーバを運用しています。私自身もエンジニアではありますが部のマネージャも兼ねているため、立場上、社外の方からインフラエンジニアのマネジメントについて質問されることがよくあります。今回は、私自身の考え方とクックパッド社における事例を紹介したいと思います。 「インフラエンジニア」とは 「インフラエンジニア」という言葉の定義はあいまいで、しばしば議論の的になります。傍目からは明らかにインフラエンジニアであるように見えるにも関わらず「私はインフラエンジニアでは無い」と主張する人たちもいます。このような状況になっているのは、サーバ運用に関する業務分掌が会社ごとに異なるからであると私は考えて
ssig33.com - docker ホストを長期間運用する際の注意点
うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SRE 研修
大規模ゲームインフラとしての Kubernetes とノーメンテナンス運用
クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と成功について // Speaker Deck
Slerがawsで運用してきた話
運用を楽にするためのアプリケーションコードを書くということ : sonots:blog