正しく運用されているかを評価するのが監視である～ゼロからの運用監視設計（前編）。July Tech Festa 2016
正しく運用されているかを評価するのが監視である～ゼロからの運用監視設計（前編）。July Tech Festa 2016 運用監視の自動化は、複雑化するアプリケーションやサービスに対して効率的かつ確実な運用監視を実現する上で、またコスト削減の意味でも重要な要素になってきています。運用監視の自動化は、どのように考えて実現していけばいいのでしょうか。 7月24日に産業技術大学院大学で行われたイベント「July Tech Festa 2016」のセッション「運用自動化のための Re:ゼロから始める監視設計」は、そのための知見を得る上で大変参考になるものでした。この記事では、そのダイジェストを紹介します。 運用自動化のための Re:ゼロから始める監視設計 前佛雅人氏。 今日の私の話は、業界経験が豊富な方には当たり前すぎる内容かも知れませんが、自分だったら20年前にこれを知りたかったな、ということを
インフラエンジニアがGo言語でオペレーションツールを書くことについて - Hatena Developer Blog
ウェブオペレーションエンジニアの id:y_uuki です。 はてなの東京オフィスで先月開催されたGo 1.6 Release Partyで、「Writing Tools in Go For Ops Engineers」というタイトルで発表しました。 発表では、最近作ったGo製ツールを紹介し、なぜGoがインフラエンジニアにとって良い言語であると感じているかを話しました。 最近作ったGo言語のツールの紹介 mkr Grabeni Droot gokc インフラエンジニアがGoを利用することのメリット 1. サーバへの配布が簡単 2. サーバ上で高速開発できる 3. 最終的に成果物をはやく作れる その他 発表資料 あとがき 最近作ったGo言語のツールの紹介 以下の4つのツールを作りました。いずれもはてなでのproduction利用を想定したものになります。 mkr mkrははてなで開発している
日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ
私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当？ これは、私がマイクロソフトの面接の時に、当時
Etsyの「失敗から学ぶ文化」 ～Velocity Conference 2015レポート #2～ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！kintone開発チームの田中裕一(@yuichielectric)です。 こちらの記事に引き続き、Velocity Conferenceに参加して、面白かったセッションの内容を紹介しようと思います。 Velocity Conferenceについては前回の記事を参考にしてみてください。 Failure is an option 今回紹介するのは前回と同じ Etsy の Ian Malpass(@indec)さんによる"Failure is an option"というセッションです。 このセッションでは、Etsyでの失敗に対する扱いや、失敗からいかに学ぶかという文化的な話と、その文化を支えるツールが紹介されました。失敗をどう扱うのかという考え方は非常に参考になり、それを恐れるよりもうまく乗りこなすことが重要なのだということがよく分かるセッションでした。 また、スピーカーの方のブロ
今さら聞けない Immutable Infrastructure - 昼メシ物語
Immutable （不変な） Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S
ansibleを使ってみる — そこはかとなく書くよん。 ドキュメント
ansibleを使ってみる¶ Chefが猛烈な勢いで流行り始めている今日このごろですが、似たようなものは 世の中にいくつもあります。今日はその中の一つ、 Ansible を使ってみます。 書いていたらやたらと長くなったので何回か続きます。 軽くご紹介¶ インストールの前にどのようなツールなのかを軽く説明します。マシンの設定 を自動で行なってくれる、というツールなのはChefと同じです。 そのポリシーは githubのページ に書かれています。 シンプルな設定 最初から超速くて並列 サーバーやデーモンとかいらない。今あるsshdだけあればいい クライアント側になにもいらない モジュールは「どんな」言語でも書ける 超強力な分散スクリプトを書くためのイケてるAPI rootじゃなくても便利に使える 今までで一番使える設定管理システム さて、では見て行きましょう。 インストール¶ ansibleは
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（前編）～DevOps Day Tokyo 2013
GitHub社内のDevOpsを支えるツール「Boxen」と「Hubot」（前編）～DevOps Day Tokyo 2013 世界中でDevOpsのイベントとして行われている「DevOps Days」の東京版「DevOps Day Tokyo 2013」が9月28日に開催、海外から来日した多くのゲストスピーカーによるセッションが行われました。 GitHubのJohn Britton氏は「Ops for Everyone」（みんなの運用）という題で、GitHub社内で開発から運用までをデベロッパー自身が行うためのツール、BoxenとHubotの紹介と社内の利用例を解説しています。 Ops for Everyone John Britton氏。 GitHubでエンジニアと教育の橋渡しをしています。
Chef-soloとAnsibleとFabricを試した感想 · hnakamur's blog
2013-09-01 Chef-soloとAnsibleとFabricを試してみたので感想をメモ。どれもそんなに深くは使い込んではいない。 このメモは自分の脳内の考えを整理するためのもので、人が使うことについてどうこう言うつもりはないです。 Chef-solo 書いてみたcookbookはこちら。hnakamur/chef-cookbooks hnakamur/chef-repo クックブックは手順を書くのではなくて結果を書くというのがどうも本質的に違うと私は思ってしまう。料理のレシピだって手順を書くし。書結果がこうあるべきというのはserverspecが出来た今となってはそちらに任せて、クックブックは本来手順を書くべきものだと思う。 RubyのDSLだけど結局上から順に評価されるので、実は手続きを書いていることになっている。でもファイル単位でしか再利用できないので、一部だけ使いたいと思っ
テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき
DevOpsの今とこれから #init_devops
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
資料公開 Vagrant (+Amazon EC2)
著作 SCRUM BOOT CAMP THE BOOK 著者／訳者：西村直人 永瀬美穂 吉羽龍太郎 出版社：翔泳社( 2013-02-13 ) 定価：￥ 2,520 スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社：インプレス( 2014-09-19 ) 定価：￥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによる
目次
要求を満たすシステムを構築するのは難しいが、もっと難しいのはシステムに改良を加えつつ安定的に動作させることだ。この難題に対して、これまでは無策すぎた。開発と運用のスキルセットは大きく異なるので担当者を分けるのは理にかなっている。だが、組織を分けるとそこに「壁」ができてしまうものだ。壁を取り払い「Dev（開発）とOps（運用）が協力して難題に立ち向かおう」―。そう訴えているのが「DevOps」である。すべてのITエンジニアが目指すものではないだろうか。 本特集はエンジニアの本音を聞いたうえで、難題に取り組んだ現場の軌跡、お勧めする実践法、ネット企業の取り組み、PMやアーキテクトの提言など、さまざまな視点を取り上げた。あなたの現場に役立つヒントを見つけてほしい。
5分で分かった気になるDevOps
最近あっちゃこっちゃでDevOpsという単語を聞きますが、概念的な言葉でスコープが広いので簡単に整理しておくことにします。 これで5分くらいで分かった気になるかもしれません。 2009年にFlickrの人が発表した概念 http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 概念なので、実装は個々の現場によって異なる。アジャイル開発とアジャイル開発方法論の関係のようなもの。 従来型の考え方による利害対立 Devは多くの機能を早く届けなければならない すばやい変化 Opsは安定した運用を行いトラブルを起こさないようにしなければならない 変化を避けたい それじゃビジネスに勝てない DevOpsとはDevとOpsが協力しながら、ビジネスのために継続的に成果を出す、もしくは変化に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】The Basics of DevOps
運用を楽にするためのアプリケーションコードを書くということ : sonots:blog
クックパッドのインフラ責任者が語る、DevOpsを成功させる考え方「迷ったら健全な方を選ぶ」～DevOps Day Tokyo 2013