クックパッドがどのようにMicroservicesしてきたか/How Cookpad shifts to MicroservicesクックパッドがどのようにMicroservicesしてきたか/How Cookpad shifts to Microservices
はてなでの サービス信頼性向上のための 取り組み事例
SRE Tech Talks ( http://connpass.com/event/34825/ ) でお話した際の資料です
Writing a Friendly README
A README is one of the first things people see when they find your open source project. It should be helpful, welcoming, and friendly. Posted on 14 March 2016 by Rowan Manning. Tagged with Open-Source, Writing, Documentation 87 responsesSyndicated to Twitter Your project’s README is pretty important; it’s often the first thing that a person new to your project will see, and is frequently the only
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
継続的インテグレーションのツール「Jenkins 2.0」登場。標準機能を豊富にして初期状態から利用しやすく、旧バージョンからそのまま入れ替え可能な後方互換性維持
継続的インテグレーションのツール「Jenkins 2.0」登場。標準機能を豊富にして初期状態から利用しやすく、旧バージョンからそのまま入れ替え可能な後方互換性維持 継続的インテグレーションなどに利用されることが多い自動化ツールJenkinsの最新版、「Jenkins 2.0」がリリースされました。 Jenkins 2.0 is here! https://t.co/KjHrIf8cj4 #jenkins2 — Jenkins (@jenkinsci) 2016年4月26日 Jenkinsはビルドやテスト、デプロイなどのソフトウェアの開発に関わるさまざまな一連の作業を自動化してくれるツール。継続的インテグレーションや継続的デリバリの現場でよく使われています。 Jenkins 2.0では、こうした一連の作業をより効率的かつ高度に記述できるようにパイプライン機能を強化。GroovyのDSL（ドメ
【資料公開】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
ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
日本と米国で異なる「想定する物量」がソフトウェア開発の生産性の違いを生む - メソッド屋のブログ
私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この２つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは１つのことをこなすための「物量」が違うということです。
Graphite Documentation — Graphite 1.2.0 documentation
© Copyright 2008-2012, Chris Davis; 2011-2021 The Graphite Project Revision b52987ac.
スタートアップ向け監視設計入門::Innova EngineerBlog
Image from Datadog はじめに こんにちは。エンジニアのみかみです。DevOpsを推進するための、ビルドツール、CI、監視系の設計や管理ツールの作成を担当しています。インフラエンジニアっぽいですが、実際はチーム内の困ったを拾うキャッチャーで、よろず相談屋をやっています。 さて、今回は監視についてのお話です。 最近、安価で柔軟に使えるクラウドサービスが提供され、新規サービスの開発が容易になりました。 しかし、サービスをリリースしたものの、ある程度サービスが認知されてくると突然システムが故障したり、予期せぬ不具合が突然発生し困ったことはないでしょうか？ サービスの稼働率を100％保証することは技術的に難しく、サーバー稼働率99.9％を保証しているサービスが多いですが、この数字でも年に9時間は停止する計算になります。100%の動作保証が難しいのならば、何時停止したとしても、すぐに
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
Webオペレーションエンジニアのアウトプットと開発力 - 人間とウェブの未来
という話を、社内のインフラチーム向けにしました。 Webオペレーションエンジニアの大体のイメージについてはこちらを御覧ください。書評なのですが、とてもイメージしやすいエントリになっていると思います。 blog.riywo.com スライドの中でも一応定義していて、３行にまとめると Webサービスの運用 OS・ミドルウェアの運用 運用技術の調査・開発 を主な業務として行っているエンジニアを指すことにします。 入社して間もないので、僕の人格の好き嫌いや人間関係みたいなものがまだできていない頃の発表ということで、素直に内容を聞くことができる、という意味でいい機会だったと思います。 この内容は、社内だけでなく社外のWebオペレーションエンジニアや、所謂、インフラエンジニアと呼ばれている人でも同じような悩みを抱えている人がいるかもしれないと思っていて、内容的にも公開しても良い話なので公開しようと思い
Consul は 全自動オーケストレーションの 夢を見るか?
- version 1.02 (July Tech Fest の資料アップデート版です) Re: ご注文は自動化ですか？[2] オーケストレーションで仕事を楽しくする話 Serf とか Consul とか聞くけど、イマイチわからん！という疑問はありませんか。 どのような働きをするのかや、使いどころを、皆さんと共有したいなと思っています。 1. オーケストレーションとは ← update! 2. 基本編 ・ Serf, Consul, envconsul 3. 実践編 ・ API 連携 4. まとめ #hbstudy 60 http://connpass.com/event/7322/ July 20, 2014, @ Shinjyuku, Tokyo, Japan
%25E6%258A%2580%25E8%25A1%2593)
Treasure Dataを支える(中の人に必要な)技術 - myui's memo
Treasure Data（以下、TD）に入社して早2週間が経ちました。 入社してから、平成14年度IPA未踏ユース第1期で同期でスーパークリエイタであった西田さんがTDで働いているのを知りました。MapReduceやHadoopが登場した頃、「Googleを支える技術」という技術書*1でお世話になったのですが、いつの間にかTreasure Dataを支える人になっていたんですね*2。 Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ) 作者: 西田圭介出版社/メーカー: 技術評論社発売日: 2008/03/28メディア: 単行本（ソフトカバー）購入: 47人 クリック: 1,166回この商品を含むブログ (374件) を見る TDではおかげさまで結構なペースでお客さんが増えていて事業規模拡大に備えて幅広い職種で人材募集中です。今回はTDのバッ
【特別企画】ソーシャルゲームのDevOpsを支える技術（前編）～魔法少女リリカルなのはINNOCENTの舞台裏～ | gihyo.jp
【特別企画】ソーシャルゲームのDevOpsを支える技術（前編）～魔法少女リリカルなのはINNOCENTの舞台裏～ モバゲーから提供されているソーシャルゲーム『魔法少女リリカルなのはINNOCENT』は、企画・開発・運用を（株）ユビキタスエンターテインメントが行っています。このサービスを支えるインフラは物理サーバと仮想サーバのハイブリッド構成となっており、（株）IDCフロンティアのクラウドサービスが採用されています。本稿はこの両社から、人気ソーシャルゲームならではのデータを交えながら、DevOps実現に向けての取り組みを披露してもらいます。 どんなゲームなの？ 『魔法少女リリカルなのはINNOCENT』は2013年3月にモバゲーにてリリースされたソーシャルゲーム[1]です。原作者の都築真紀氏がこのゲームのために構築した世界観、従来のカード型ソーシャルゲームのシステムを踏まえつつも他作品
デプロイ自動化とServerspec
Serverspec本の献本ありがとうございました．とても面白かったです．詳しい書評はすでに素晴らしい記事がいくつかあるので，僕は現チームでどのようにServerspecを導入したか，どのように使っているかについて書きたいと思います． Serverspec導入の背景 今のチームではサーバーのセッアップおよびデプロイにChefを使っている．本にも書かれているようにこのような構成管理ツールを使っている場合はそのツールを信頼するべきであり，Serverspecのようなテストツールは必要ない．僕らのチームもそのような理由でServerspecの導入には至っていなかった． しかしアプリケーションが複雑になりChefのレシピも混沌とするようになるとそれは成立しなくなる．見通しの悪いレシピはChefへの信頼度を落とす．信頼度の低下はデプロイ不信に繋がり人手（筋肉）によるテストが始まる． サーバーの数がそ
chefに疲れたあなたにはItamaeがおすすめ！ - ゆーじのろぐ
chef使うのめんどくさくないですか？ 私はいままでサーバーの設定を自動化するためのツールにchefを使っていました。 最初chefを使い始めた時は、いままで手作業でやっていたことがコード化・自動化できるので「お、便利ー！chef最高！」という感じだったのですが、 だんだん使っていくうちにchefが高機能が故に自分の用途としては使うのが辛くなってきました。 そもそも自分はchef soloしか使わない chef は基本的にはchef-server - chef-client という構成で、設定を自動で行いたいサーバーに対してchef-clientをインストールします。 そして対象のサーバーの設定をコード化したrecipeを保持するchef-serverとchef-clientが通信して対象サーバーにrecipeを適応します。 このchef-serverを立てずにchef-clientだけで
DevOpsが浸透しない「本当の理由」
欧米では業種を問わず、多くの企業に浸透しているのに対し、国内ではいまだバズワードと見られているDevOps。その真因とは何か？ アジャイル開発、DevOpsに深い知見を持つ、日本HPの藤井智弘氏が「DevOpsの誤解」の真因を喝破する。 DevOpsが、日本ではスローガンから脱し切れない理由とは？ ビジネスとITの距離が年々縮小し、ITのパフォーマンスがビジネスのパフォーマンスを左右する時代になっている。特に現在、SoE（System of Engagement）領域に属するフロント系のシステムは、業種を問わず多くの企業が運用している。市場環境変化が速い中、こうした顧客接点となるシステムはもちろん、それと連携するバックオフィスのシステムも含めて、ニーズに合わせて迅速・柔軟に改善できなければ、ライバルも多い中で確実に機会損失を被ることになる。これを受けて、欧米では金融、メーカー、流通など、多
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスト駆動インフラ構築-Chefとserverspecを使ったインフラ自動化のすすめ-
Kibanaでログ分析を1年続けてみたら業務システムの保守と運用が捗った / How&Why I have been leveraging Kibana for DevOps
