メルペイのシステム運用とPlaybookの共通管理への挑戦 | メルカリエンジニアリング
こんにちは、メルペイでSREとして従事している @myoshida です。この記事は Merpay Tech Openness Month 2021 の8日目の記事です。 SREチームはお客さまへよりよいサービス利用体験を提供するため、日々様々な改善活動に取り組んでいます。その活動の一環としてPlaybookの概念を導入し、運用者の運用負担を減らす取り組みを始めました。今回はそのことについて説明してみたいと思います。 概要 メルペイではアプリケーションエンジニアとSREの双方がオンコール制度のもと運用に携わっています。 運用の悩みは様々ですが、そのうちの1つに手順書の取り扱いがあります。 どこに置くべきか、更新はされているのか、何を書けばいいのか、どの場面でどの手順書を利用すればよいのかというような悩みはどこの現場でも少なからず存在すると思います。 そこで、Playbookと呼ばれる体系的
なぜメルペイQAはDevOpsに取り組むのか？ | メルカリエンジニアリング
Merpay Advent Calendar 2020 の18日目は、QAエンジニアチームの @miisan がお送りします。 昨年のMerpay Advent Calendar 2019で 「メルペイQAの今と未来と私の日常」 というTech Blogを書かせていただいてから約1年たちました。メルペイではこの1年で、さらに多くの機能をスピード感を持って、お客さまに届けてきました。 今回は、メルペイQAがDevOpsサイクルの中で、普段どのような取り組みを行い、プロダクトを支えているかについて紹介したいと思います。 最初に結論をお伝えしてしまいます。ひとことで表すと、「お客さまにより早く、より確実に、より良いサービスを継続的に届けるため」です。 DevOpsの良いところ 協力体制：役割に関係なく、サービスの価値向上に目的意識が向き、プロダクト全体に対して活動できる。 信頼性向上：責任範囲を
The SRE model
Cindy Sridharan’s fantastic article on why everyone is not ops makes you rethink of the relationship between your development and operations teams. In this article, I am trying explain how Google approaches the problem and why it scales for our SRE team. At Google, SRE stands for site reliability engineer. Site reliability is about velocity and productivity of our engineers, the performance and re
GoogleとNetflix、カナリアリリース分析ツール「Kayenta」オープンソースで公開。新たにデプロイしたリリースに問題がないかを自動分析
GoogleとNetflix、カナリアリリース分析ツール「Kayenta」オープンソースで公開。新たにデプロイしたリリースに問題がないかを自動分析 GoogleとNetflixは、共同開発したカナリアリリース分析ツールの「Kayenta」をオープンソースで公開した。新規リリースを本番環境に対して小規模にデプロイし、問題がないかを検証する作業を自動化。より迅速で確実な継続的デリバリを実現する。 GoogleやNetflixのようにWebサービスを提供している企業では、そのWebサービスに次々と改良が加えられ、1日に何度も新しいリリースがデプロイされています。 しかし新しいリリースのデプロイはいきなり大規模に行われるわけではありません。リリースされるコードに対しては継続的デリバリのパイプラインの中で一通りの自動テストが行われ、ある程度の品質が保証されているはずです。しかし、それでも新しいリリー
自動化対象のユニットテスト（単体テスト）の仕様書を書くことは完全なる無駄である
本ブログポストは、マイクロソフトの意見ではなく、私個人の意見であることをお断りしておきます。 DevOps 普及活動の一環として、DevOps ハッカソンというイベントを実施しています。DevOps のプラクティスの一つとしてAutomated Testing (自動化されたテスト) があります。 それに関して複数の参加者の皆さんがこのようなことを言っていました。 「自動テストを書くのは好きではないです。何故かというと、自動化されたユニットテストを書いたら、同じ内容のエクセル方眼紙の仕様書を書かないといけないので、二重に書くのは無駄だし大変だと思うんです。」 はっきり言ってしまうと、このケースの単体テスト仕様書は完全なる無駄であると断言できます。 このポストではその理由をお話ししたいと思います。 1. 単体テストのイメージの違い この問題が起きている背景には、「単体テスト」というものがCO
[Android][Gradle] ライブラリプロジェクトのJaCoCoでのカバレッジ計測
Android Studioがリリースされて以来、Gradleプラグインをしばらく使っていたものの androidプラグインがjavaプラグインと共存できないせいでいろいろとできないことがあった。 その一つが、カバレッジの計測。 4月末のAndroid Gradle Plugin 0.10.0のリリースでJaCoCoのサポートが追加され、ついにandroidプラグインでもカバレッジ計測ができるようになった。 http://tools.android.com/tech-docs/new-build-system 気づいて早速使おうとしたものの、上記ページに書かれている他はほとんど書かれているところがなくうまく動かず。。。 また、動かそうとしたのが単純なAndroidアプリケーションプロジェクトでなくライブラリプロジェクトであり、Eclipse互換の構造を保とうとしながら作っていたせいかもしれ
「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ - エンジニアtype | 転職type
転職・求人情報サイトのtype エンジニアtype スキル 「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ 「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業が行うべき最も重要なことである。良いプロダクトさえあれば、マネタイズやマーケティングの戦略もすべて後付けで立てられるからだ――。 Google会長のエリック・シュミット氏が著書『How Google Works』でこう述べるように、インターネットをベースにビジネスをする企業にとって、プロダクトを開発・発展させることこそがすべてである。ことさらスタートアップとなれば、開発・改善のスピードが大手と競争するための源泉となるだろう。 そんなスタートアップのエンジニアや、今後転職を考えるエンジニアを応援すべく、1
ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) | 株式会社ヌーラボ(Nulab inc.)
このエントリは前後編に分かれています。前編は主に運用フローやそこでの工夫点、後編は実際の運用から得た知見や今後の課題といった内容です。 ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (前編) ヌーラボのインフラ運用最前線 〜イミュータブルを目指して〜 (後編) 最近はインフラ運用・DevOPS関連のトピックとして目にしないことはないくらい、「イミュータブルインフラストラクチャー」について様々な議論がなされています。私たちも昨年、継続的デリバリという文脈で、@IT の連載にてその基本的な考え方について紹介させていただきました。 さて、今年の二月にローンチをしたばかりのヌーラボのシングルサインオンサービス「ヌーラボアカウント」では、イミュータブルインフラストラクチャの一歩手前として、特定の変更を加える場合のみ、ごっそり環境ごと入れ替えるというやり方にてその運用をスタートしました。
Chef のレシピから serverspec のテストを自動生成する chef-serverspec-handler という gem を作ってみた - P A R A G R A P H S
tily/chef-serverspec-handler · GitHub 『Chef のレシピは「こうあるべき」を記述するものだから、レシピからテストが自動生成できるべきだよな』とずっと思っていたんだけど、最近触りはじめた serverspec がシンプルで簡単に自動生成できそうなのでやってみた。 使い方は上記リンクに書いてある通りなのですが、たとえば Chef のレシピにこう書いてあるやつを、 template '/var/tmp/template.txt' do source 'template.txt.erb' mode 0777 owner 'root' group 'root' variables(:val1 => 'val1', :val2 => 'val2', :val3 => 'val3') action :create end このような serverspec のテスト
Chefを読んで実行するための全知識 - Qiita
このドキュメントでは、Chefを実行して、インフラを作成したい人が、既存のレシピがあるのを前提に、Chefの概要を理解するためのドキュメントです。Chef-soloの構成のみに対応した記述になっています。理解が間違えているところとかあればご指摘ください。 1. Chefの概要 1.1. Chefとは シェフは、インフラストラクチャーをコードに変換するための自動化プラットフォームです。仮想環境でも、物理環境でも、クラウドでも使う事ができます。インフラストラクチャを自動化することで、プロダクトのマーケット投入を早めたり、スケールや複雑さに対応したり、システムを安全に保ちます。 1.2. Chefの仕組み Chefはサーバーをセットアップして、希望の状態にするための「クックブック」「ノードオブジェクト」というDSL(設定ファイルっぽいもの)をローカルのワークステーションで作成します。それらのDS
工数削減だけじゃない、自動化ツールの真のメリット
工数削減だけじゃない、自動化ツールの真のメリット：運用自動化ツールまとめ（国内ベンダ編）（1/4 ページ） 運用自動化というと「人員削減」「コストが掛かる」といったネガティブな見方をする向きも多い。だが仮想化、クラウド時代において運用自動化とはそれほど単純なものではない。国内ベンダ4社のツールに真の意義を探る。 仮想化技術の浸透に伴い、2008年ごろから国内でも注目を集め始めた運用自動化。だが、「人が削減される」「コストが掛かる」「万一の時が不安」といったネガティブな見方も多く、導入企業は現在も一部にとどまっている。しかし近年、市場環境変化がさらに加速し、ビジネスを遂行するIT基盤を迅速・柔軟に整備・変更する必要性が増している。こうした中、もはや人手だけに頼った運用では、ビジネス部門の要請に応えられないばかりか、人的ミスも誘発しやすい状況になっている。こうした状況は以下の記事に詳しい。 情
Infrastructure as Code - naoyaのはてなダイアリー
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
ナウいツールやサービスなどのまとめ - Qiita
国内注目のWebサービスを支える言語・フレームワーク・アーキテクチャ一覧【2013年版】 をもとにナウい感じのサービスなどをまとめた。分類がおかしいかもしれないのん コード管理 ソースコードは Git で管理しているところが増えている Git GitHub GitHub Enterprise: Enterprise 向け Gitlab Gitlab Cloud Gitlab CE: オープンソース Gitlab EE: Enterprise 向け BitBucket Stash: Enterprise 向け codebreak; RhodeCode Gitorious GitPrep GitBucket GitHubクローンまとめ 無料でGitHubのような機能を実現するための候補 | Act as Professional - hiroki.jp 料金 private repositor
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
<!-- "> '> --><title>