運び屋 (A carrier(forwarder) changed his career to an engineer)

Network / Cloud Native / Kubernetes / コンテナー / SRE / DevOps

SRE / DevOps / Kubernetes Weekly Reportまとめ#66(2021/5/2)

The English Version of this blog is here.

この記事は2021/5/2発行の下記2つのWeekly Reportを読み、備忘録兼リンク集として残しているものです。(KubeWeeklyは今週休み)

なるべく情報を早く届けたい/共有したいので、ブログのリンクを確認次第、先行公開しています。自身のコメントは随時追加しています。

  • 誰かの情報源や検索工数削減などになれば幸いです。
DEVOPS WEEKLY ISSUE #540 May 2nd, 2021
SRE Weekly Issue #268 May 2nd, 2021
KubeWeekly #262 May 21st, 2021←KubeCon + CloudNativeCon Europe 2021のためKubeWeeklyは2週間休み、5/21に再開予定。
  • この記事を読んで疑問点や不明点があれば、URLから本文をご確認の上、ご指摘頂ければ幸いです。
  • 理解が浅いジャンルも、とにかくコメントする様にしていますので、私の勘違いや説明不足による誤解も多々あろうかと思います。
  • 情報量が多いので文字とリンクだけに絞っております。
  • 各レポートで取り上げられている記事には2020年以前のものもあり、必ずしも最新のものという訳ではない様です。

DEVOPS WEEKLY ISSUE #540 May 2nd, 2021

News


An interesting post covering a few topics, including Backstage as a platform for developer context and the movement to shift cloud cost control to development teams.
  • タイトルは「Shifting cost optimisation left: Spotify Backstage Cost Insights」。
  • Spotifyの文化、アプローチ、テクノロジー、「オープンソース化したBackstage Cost Insights」で達成したいこと、またSpotifyのプラクティスに基づいて他の企業が同じアプローチを採用する方法を解説している。
  • Webページの末尾にこの調査の元となっているSpotifyの従業員へのインタビュー動画が埋め込まれている。
A post on the importance of planning and runbooks for important operational activities, and a tribute to the astronaut Michael Collins, who passed away this last week.
  • タイトルは「Michael Collins — Carrying The Fire」。
  • 上記の通り、先日亡くなった宇宙飛行士Michael Collins氏を追悼し、runbookの重要性を解説している記事。
A nice post stepping back over the last 20+ years and considering the evolution of operations and the technology we’re operating.
  • タイトルは「The evolution into DevOps and why it works today」。
  • タイトルと上記Editorのコメント内容を以下の項目に沿って解説している。
    • Act 1: Early to mid 90s and the rise of dot com
    • Act 2: Late 90s, early 2000s and the rise of internet hyper-growth superstars
    • Act 3: The 2010s, beginnings of cloud-native, and high-availability cloud
    • Why DevOps works today and what to keep in mind
All of the videos from the DevX event last week have been posted, covering all things developer experience. This has been a focus for lots of teams building developer tools as the expectations have increased over the last several years.
  • 上記の通り、先週開催されたDevXのYouTube動画のプレイリスト。
A post on the importance of games as learning tools for operations teams, for improving team communication, incident response, delegation and more.
  • DevOpsチームがプレイできるゲームについて解説をしている。
  • 解説の中で主流のゲームから、チームとシステムの回復力をテストするDevOps固有のゲームまで、さまざまな種類のゲームについて触れている。
    • 基本的なチームビルディングから、関連性の高いスキルとコアコンピテンシーの慎重な実践など。
    • パーティーゲームからGamedayまで、ゲームをプレイする仕組みと利点を分類している。
  • チームでのプレイタイムをスケジュールし、チームを成長させるための次のステップとして、最適なゲームの種類の選択に必要なアイデアが得られる。
A description of various anti-patterns when it comes to operating models, and in particular assuming one size fits all when it comes to large organisations.
  • タイトルは「The Usual Suspects (Operating Model anti-patterns)」。
  • タイトルと上記のEditorのコメント通り、Operating Modelのアンチパターンを解説している。筆者の意図が冒頭の部分に込められている。
    • This blog proposes alternatives to operating model copy/paste snake oil.
There are now lots of SaaS services to help handle distributed logging challenges. This post (from one of the included vendors) provides a handy list and overview of some of the current offerings.
  • タイトルは「9 Best Cloud Logging Services for Log Management, Analysis, Monitoring & More [2021 Comparison]」。
  • 冒頭にCloud Log Management Serviceの必要性を解説し、以下の9つのサービスを紹介している。
    1. Sematext
    2. SolarWinds Papertrail
    3. SolarWinds Loggly
    4. Sumo Logic
    5. LogDNA
    6. Datadog
    7. Amazon CloudWatch Logs
    8. Microsoft Azure Logs
    9. Google Operations (formerly Stackdriver)

Jobs

Are you interested in challenges outside "the cloud"? Would you like to utilize software engineering for best-in-class tailored solutions to our infrastructure? Would you like to participate in the design and implementation of core infrastructure systems?

Join Optiver as Infrastructure Software Engineer!

We look for Engineers with Linux Servers experience and an ability code in Python or have the propensity to pick it up. If you don't consider yourself a developer, no problem! We’re also looking for individuals able to do scripting while working with Linux or networking low levels. Take a look here for further details of the role and how to apply:

www.optiver.com

  • Infrastructure Software Engineerの求人情報。

Events

Monitorama is back, on the 13th to the 15th of September in Portland, Oregon. Yes, a real life in-person event. As always Monitorama will bring together the open source and operations communities in pushing the boundaries of observability software and practices.
  • 上記の通り、Portland, Oregonで9/13-/15にリアルイベントとして開催予定。

Tools

Teller is a command line tool for managing and accessing secrets. It supports Hashicorp Vault, AWS Secrets Manager, Google Secret Manager, and more for secure storage.
  • 開発者向けのユニバーサルなSecret Manager「Teller」のGitHubページ。
gRPCurl is a command line tool for interacting with gRPC endpoints. It can browse remote schemas, show protocol buffers and send requests using JSON as input.
  • gRPCサーバーと対話できるコマンドラインツール「gRPCurl」のGitHubページ。

SRE Weekly Issue #268 May 2nd, 2021

Articles

Manageable On-Call for Companies without Money Printers

The SRE book has a chapter covering on-call, but it’s best suited for huge-scale companies. What should the rest of us do?

Utsav Shah

  • 上記のEditorのコメント通り、SRE本の内容のOn-Callについて補足する内容。
  • 筆者はSRE本の「Chapter 11 - Being On-Call」に記載の内容は無制限のリソースと人員を持つ一見ユートピア的な企業にのみ適用されるように思われるアドバイスに見えるため、以下の観点で解説している。
    • So I wanted to frame some of their concepts in a way that’s useful for smaller organizations, explore some even more basic principles around both technical and organizational aspects of managing sustainable on-call rotations for all sorts of software teams, and hopefully give some practical advice.
Breaking the top five myths around chaos engineering

If you’re feeling hesitant about chaos engineering, or you’re trying to convince someone who is, this might be useful. The myths are:

Myth #1: Chaos engineering is testing in production
Myth #2: Chaos engineering is about randomly breaking things
Myth #3: Chaos engineering is only for large, modern distributed systems
Myth #4: We don’t need more chaos – we already have plenty!
Myth #5: Chaos engineering is only for very mature teams/products

Mikolaj Pawlikowski

  • タイトル通り、上記5つのMythを解説している。
Seeing Like an SRE: Site Reliability Engineering as High Modernism

Drawing parallels to the high modernism movement during the cold war, this article raises interesting questions about the direction SRE is going, and system administration in general.

Laura Nolan — USENIX

  • 冒頭に、筆者が最近「ソフトウェアシステムで何を監視するかについての一連の一般的なガイドラインを書こうとして時間を費やした」ことと、作成したOKリストの紹介から始まる。
  • ソフトウェアのオペレーション全般、特にSREのオペレーションの多くは特定のシステムに関する多くの(ドメイン)知識が必要である、という観点で解説している。
Is faster actually safer? How software physics beats human psychology

Riffing off of a tweet by Charity Majors, this article explores the idea that moving faster can actually be safer, despite an urge one may feel to slow down.

Bruce Johnston

  • 「デプロイが遅いと、品質が向上し、バグが少なくなる」という心理的な判断に対して、タイトルにある投げ掛けを行い、こうした判断の分析と、そうした判断を変える際の考え方を解説している。
NTSB Aircraft Accident Report: Eastern Air Lines, May 5, 1983

An extreme oversimplification of this incident would be: multiple engine failure on a plane subsequent to a maintenance error on all engines. This accident is cited as a reason to have separate mechanics work on each engine, in hopes of avoiding duplicated errors.

US National Transportation Safety Board (multiple authors)

  • 上記のNational Transportation Safety Board(NTSB)の飛行機事故のレポート。
  • 久しぶりにこうした白黒で手書きのメモが書かれているレポートを見た。
How we ship code faster and safer with feature flags

[…] in order to ship new features and improvements faster while lowering the risk in our deployments, we have a simple but powerful tool: feature flags.

Alberto Gimeno — GitHub

  • タイトル通り、「feature flag」を利用してコードをより早く、安全に世に出しているGitHub社の知見を共有している。
    • Reducing deployment risk
    • Working on new features
    • Testing features
    • Different shipping strategies
    • What to flag
    • The cost of a feature flag
    • Conclusion
Reverse debugging at scale

This one blew my mind. By recording instruction execution traces in a ring buffer, they’re able to reconstruct enough information to step through the execution leading up to a crash — even though they weren’t running the application under a debugger!

Walter Erquinigo, David Carrillo-Cisneros, Alston Tang — Facebook

  • 冒頭にデバッグする際の望ましくないシナリオを案内し、インタラクティブで視覚的に開発者が本番環境と開発環境の問題をはるかに効率的な方法で解決するのに役立つデバッグツールを構築して対応する方法を解説している。
The Plane Paradox: More Automation Should Mean More Training

Automation is supposed to take some of the load off of the human operator, right? But in reality, humans need to build a mental model of what the automation is doing in order to use it safely and effectively.

Shem Malmquist — WIRED

  • 自動化について、運用者として持つべきメンタルモデルを航空機パイロットを例に解説している。以下のコメントが象徴的。
    • it requires much more training and experience, not less, to fly highly automated planes.
    • Until automation can account for its own surprises, we need to make sure humans can.

Outages

上記各社の障害情報


KubeWeekly #262 May 21st, 2021←KubeCon + CloudNativeCon Europe 2021のためKubeWeeklyは2週間休み、5/21に再開予定。

いかがでしたか?気になる記事や情報はありましたか?

私もまだ内容を咀嚼出来ていないものが多々ありますので、この備忘録兼リンク集を活用しながら理解を深めていきたいと思います。

では、また。

Bye now!!

Yoshiki Fujiwara