<!-- "> '> --><title>
SRE の原則に沿ったトイルの洗い出しとトラッキング | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 2 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 作業効率を検証するために Google のサイト信頼性エンジニア（SRE）が使用している主な測定指標の一つが、日々の時間の使い方です。長期間のエンジニアリング プロジェクトのために時間を確保する必要がありますが、エンジニアには Google のサービスを稼働し続ける責任もあり、そこにも手作業が生じることがあります。Google の SRE は、いわゆる「トイル」に費やされる時間を勤務時間の 50% 未満にすることを目指しています。では、トイルとは何でしょうか。トイルに邪魔されずに開発スピードを維持するには何をすべきでしょうか。本稿ではこれらの問いについて見ていきます。 まずトイルの定義ですが、『Site Reliability Engineering』の第 5 章には次の
SRE チームの評価に役立つレベル別チェック リスト | Google Cloud 公式ブログ
※この投稿は米国時間 2019 年 1 月 26 日に Google Cloud blog に投稿されたものの抄訳です。 このたび、『The Site Reliability Workbook』がウェブサイトで閲覧できるようになりました。Google で生まれ、他の企業にも広まりつつある Site Reliability Engineering（SRE）は、運用上の問題をソフトウェア的に解決するためのエンジニアリングであり、Google におけるエンジニアリングの本質的な部分を占めています。 SRE は考え方であり、一連のプラクティスやメトリクスであり、システムの信頼性を保証するための処方箋でもあります。SRE モデルを構築すれば、サービスの信頼性が向上し、運用コストが下がり、人間が行う作業の価値が高くなって、サービスとチームの双方で大きなメリットが得られます。上述の新しいワークブックは、
Kayenta : Google と Netflix が共同開発したオープンソースの自動カナリア分析ツール | Google Cloud 公式ブログ
どのような規模であれ、継続的デリバリを行うには、ソフトウェア変更を迅速にリリースできるだけでなく、安全にリリースできるようにする必要があります。Google と Netflix が先ごろ発表した、オープンソースの自動カナリア分析サービスである Kayenta は、本番環境デプロイの迅速なロールアウトに伴うリスクを軽減します。 Kayenta は Google と Netflix によって共同開発されました。Netflix の社内カナリア システムを進化させ、完全にオープン、拡張可能で、高度なユース ケースに対応できるようにしたものです。Kayenta によって企業のチームは、エラーが起こりやすく時間もかかる面倒な手動またはアドホックのカナリア分析を減らし、自信を持って、変更を本番環境に迅速にプッシュできるようになります。 Kayenta は、オープンソースのマルチクラウド継続的デリバリ プ
API 設計ガイド | Cloud API Design Guide | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
GoogleとNetflix、カナリアリリース分析ツール「Kayenta」オープンソースで公開。新たにデプロイしたリリースに問題がないかを自動分析
GoogleとNetflix、カナリアリリース分析ツール「Kayenta」オープンソースで公開。新たにデプロイしたリリースに問題がないかを自動分析 GoogleとNetflixは、共同開発したカナリアリリース分析ツールの「Kayenta」をオープンソースで公開した。新規リリースを本番環境に対して小規模にデプロイし、問題がないかを検証する作業を自動化。より迅速で確実な継続的デリバリを実現する。 GoogleやNetflixのようにWebサービスを提供している企業では、そのWebサービスに次々と改良が加えられ、1日に何度も新しいリリースがデプロイされています。 しかし新しいリリースのデプロイはいきなり大規模に行われるわけではありません。リリースされるコードに対しては継続的デリバリのパイプラインの中で一通りの自動テストが行われ、ある程度の品質が保証されているはずです。しかし、それでも新しいリリー
Play by Play: Moving the NYT Games Platform to GCP With Zero Downtime
Recently I wrote about moving the platform behind The New York Times Crossword to the Google Cloud Platform and mentioned we were able to cut costs in the process. I did not get to mention the move occurred during a timeframe where our traffic more than doubled and that we managed to do it with zero downtime. Even from the start, we knew we wanted to move away from our LAMP stack and that its repl
Go で書かれたマイクロサービスの分散トレーシング | Google Cloud 公式ブログ
分散システムやマイクロサービスの開発に適しているとして、Go プログラミング言語が人気を集めています。しかし、適切なツールが揃っていなければ、Go で書かれたマイクロサービスのトラブルシューティングは非常に大変です。 Go の大ファンである私たち Google Cloud は先ごろ、分散トレーシング バックエンドの Stackdriver Trace に Go クライアント ライブラリを追加しました。これで、実行環境が Google Cloud Platform（GCP）か他のクラウドかに関係なく、あらゆる Go アプリケーションの難しいパフォーマンス問題を検出（そして解決）しやすくなります。 分散トレーシングを使う理由あるページのレイテンシ問題を解決しようとしていると仮定しましょう。そのシステムは多くの独立したサービスから作られており、そのページのデータは下流のさまざまなサービスによって
Google Omegaとは何か? Kubernetesとの関連は? 論文著者とのQA（翻訳） | SOTA
エンタープライズ向けのKubernetesサポートを行っているkismatic Inc.による“Omega, and what it means for Kubernetes: a Q&A about cluster scheduling”が非常に良いインタビュー記事だった．Google Omegaとは何か? 今までのスケジューリングと何が違うのか? 何を解決しようとしているのか? 今後クラスタのスケジューリングにはどうなっていくのか? をとてもクリアに理解することができた． 自分にとってスケジューリングは今後大事になる分野であるし，勉強していきたい分野であるのでKismaticの@asynchio氏と論文の共著者であるMalte Schwarzkopf氏に許可をもらい翻訳させてもらった． TL;DR 2013年に発表されたOmega論文の共著者であるMalte SchwarzkopfがG
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more
GoogleのCIとテスト自動化の取り組み [GTAC 2013] - ワザノバ | wazanova.jp
[Video] http://www.youtube.com/watch?v=nyOHJ4GR4iU [Slide] http://goo.gl/76Ggf Google Test Automation Conference 2013のキーノートスピーチで、GoogleのAri Shamashが同社のCIツール & 自動化されたテストプロセスを紹介しています。 [最初の前置きが13分。GoogleのCIの紹介の内容ではないので割愛。お話としては面白いのでVideo見てみてください。] エンジニア1,5000+人が5,000プロジェクトにアサインされている １億行のコード。50%が毎月更新。 1日当たり5,500+件がサブミッションされ、１億件以上のテストケースが実行されている。 Googleのクラウドテストシステムは多機能。ビルド作成、特定のターゲットをテストでき、テストカバレッジ計算、依
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Googleが解説 - 他社のSRE実践はなぜ誤りなのか
Google の新しい専門職 : CRE が必要な理由
GitHub - googleapis/google-api-ruby-client