Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ
Google、書籍「Site Reliability Engineering」の無料公開を開始。インフラや運用をソフトウェアで改善していく新しいアプローチ 「Site Reliability Engineering」（SRE）とは、GoogleのシニアVPであるBen Treynor氏が提唱した、高い信頼性や性能を発揮するシステムインフラを実現し、改善していくアプローチのひとつです。 これまでの運用チームやインフラチームによる運用や改善とSREが異なるのは、SREでは積極的にコードを書き、ソフトウェアによって目的の達成を目指している点にあるといえます。 Googleが公開しているSREのWebサイトでは、SREを次のように説明しています。 Like traditional operations groups, we keep important, revenue-critical syst
米Yahoo!、自社で利用している継続的デリバリのためのツール「Screwdriver」をオープンソースで公開。大規模インフラに対応
米Yahoo!、自社で利用している継続的デリバリのためのツール「Screwdriver」をオープンソースで公開。大規模インフラに対応 継続的デリバリとは、おおまかに言えばプログラマがコードを変更すると自動的にビルドされ、テストが実行され、問題がなければ本番環境へのデプロイが行われることで、つねに最新のリリースを迅速にユーザーへデリバリできるというものです。いわゆるDevOpsを実現する代表的な手法です。 これを実現するためには、ソースコード管理システムでソースコードがコミットされると自動的にビルドシステムが走り、ビルドの結果を自動テストにかけて、テスト結果によりデプロイが行われるなど、一連のツールが自動的に連係して動作するシステムが必要となります。 今回公開された「Screwdriver」は、この一連の自動化を実現するためのツールです。GitHubやBitbucketなどのソースコード管理
CircleCI + Docker で Infrastructure CI (Chef + Serverspec) 環境を構築した - kakakakakku blog
近況 3月から DevOps 関連の技術的負債の解消に取り組んでいて，動かなくなった Chef を直したり，秘伝のタレ（手動）で構築されたサーバ設定を Chef にリバースエンジニアリングしたり，Serverspec を導入して稼働中のサーバの差異を確認したりしている． 他にもウェブサーバのパフォーマンスチューニングをしたり，Zabbix / Kibana / CloudWatch で可視化したり，不要なアラートを消したりもした．あと Vagrant 環境を自動構築できるようにしたり，Packer を使って Vagrant Box を改善したり，デプロイ手順を正常化したり，テストの品質向上の目的で Capybara を導入したりもした． 最近はキャッシュサーバをリプレイスしたり，AWS のネットワーク構成を変更するなど，とにかく様々な施策を試しているけど，全然まだまだという感じで，圧倒的成
【資料公開】Chef ベーシックトレーニング
みなさんこんにちは。@ryuzeeです。 これから新たにChefを学ぶ人向けに非常に基本的なトレーニングの資料を作ったので公開します。 資料の構成は以下のとおりです。 まずDevOpsの文脈から自動化が必要な背景を説明Infrastructure as Codeについての利点を説明ChefのアーキテクチャChefの用語解説Vagrantで仮想マシンを2台使った一番単純なハンズオン(boxも用意済み)Serverspecを使ったCookbookのテストの書き方(VirtualBoxの仮想マシンの中でDockerを使っています)その他なお、2-3時間でさくっと触りながら全体像を掴むことを目的にしているので、網羅性はありません。 ハンズオン用のVagrantのboxには、あらかじめ、Chef DK(Development Kit)、Dockerなどが含まれており、すぐに触れると思います(ただしb
好きなPodcast
twitterでちょっとつぶやいてたけど，最近自分がよく聴いてるPodcastをまとめてみる．Tech系以外もすこし混じってる．他にオススメあれば教えてください． 日本語 Rebuild - Podcast by Tatsuhiko Miyagawa - Podcastを聴くという習慣はここから始まった．大学院生のころからずっと聴いてる．Liveもできる限り聴いてる．大ファン．取り上げる技術もすごい尖っていて面白い．全エピソード好きだけど，敢えてあげるなら，“3: MessagePack”，“14: DevOps with Docker, chef and serverspec”，“27: Dragon Quest, Docker and AngularJS”，“35: You Don’t Need API Version 2”, “37: N Factor Auth”，“42: When
serverspec インフラ層のテスト項目を考える | Ore no homepage
最近は担当システムが平和だけど俺が平和じゃない。疲れてる。忘年会の連チャンもきっついトシになっちまった。会社の制度で1週間くらい休みがとれるので、一人で温泉とスノボと開発合宿でもしに北海道にでも行こうかなって思ってる。1月か2月くらいに。 えーと、担当しているサービスにserverspecを導入した。それにあたってテスト項目を考えたので軽くまとめる。もちろんserverspec導入前もサーバ構築後は動作確認というか、テストらしいことはしていたっちゃしていたんだけど、テスト項目をまともに考えたのはこれが初めてかもしれない。serverspecのバージョンは0.13.2である。Rubyは2.0.0。 0. 環境 下記のような環境に導入した。ありふれた構成だと思う。60台くらいの規模。DBはマスタ3台に分割されていて、それぞれにスレーブがn台ぶらさがっている。LBの箱は二つあるが、物理的には1台
Fluentdが流行る理由がいま分かる、10の実践逆引きユースケース集 - Y-Ken Studio
ログデータを活用してビジネスに役立てようという最近のトレンドは理解できる。 しかし、なぜログ収集ソフトウェアのFluentdがこれほどまで話題になるのか、不思議に感じている方もいるのではないだろうか。単にログデータを収集するならばsyslog-ngやrsyslogで十分ではないかという意見もあるだろう。 それらは既存のログシステムを置き換えるプロダクトであり、Fluentdのそれとは根本的に異なる。Fluentdは、既存のログシステムに手を入れることなく新たにログの収集を行い、ストリームデータ処理を実現するプロダクトなのである。 一般的にログデータはサーバの数だけ分散しており、それを定期実行処理で収集するということだけでも、なかなか骨の折れる仕事である。さらに集めるだけでなく、日々増え続けるログデータを活用できる形に加工してしかるべきデータストアに保管するということに挫折した方もいるのでは
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
インフラチームを持たない会社でのインフラ運用
excale.net
re:workstyle
サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて