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

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

SRE / DevOps / Kubernetes Weekly Reportまとめ#72(2021/6/13~6/18)

The English Version of this blog is here.

この記事は2021/6/13~2021/6/18発行の下記3つのWeekly Reportを読み、備忘録兼リンク集として残しているものです。

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

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

DEVOPS WEEKLY ISSUE #546 June 13th, 2021

News

A post on the importance of asset management in relation to good cyber security health.
  • タイトルは「Asset management for cyber security」。
  • タイトルの内容を以下の項目に沿って解説している。
    • It’s easier to protect asset managed systems
    • Incidents and information
    • What is asset management?
    • Is asset management difficult?
    • What does good look like?
    • How to deal with unusual types of assets/OT?
    • Feedback
A large infrastructure is likely to have hugely complex network traffic flow.This post describes a state-of-the-art eBPF system for providing network insight at scale.
  • タイトルは「How Netflix uses eBPF flow logs at scale for network insight」。
  • Netflix社が開発したnetwork observability sidecar 「Flow Exporter」を利用してタイトルの課題とどう向き合っているかを解説している。
The way some cloud services work, internal data transfer costs can quickly escalate. This post looks into minimising cross-region container registry costs using a local cache.
  • タイトルは「Reducing data transfer costs with a Docker registry cache」。
  • インドのオンライン食料品小売業企業であるGrofers社では、AWSリージョンごとにコストが異なるため、開発環境にはオレゴンリージョンを使用し、本番環境にはシンガポールリージョンを使用。このマルチリージョン設定により、高くなったデータ転送のコストをどのように削減したか解説している。
An introduction to extending Prometheus monitoring systems with Thanatos.
  • タイトルは「“THANOS” — Monitoring with Prometheus and Grafana」。
  • 上記のEditorの「Thanatos」は誤植と思われる。ギリシャ神話の関係性としても、プロメテウスとタナトスが組むイメージは湧かない。
An opinionated list of 50 things you should learn to work in information security. Lots of cross-over with good security knowledge for systems administrators too.
  • タイトルは「(Technical) Infosec Core Competencies」。
  • 筆者が、Infosec分野の共通の知識体系であるコアコンピテンシーのセットと見なしている50の項目を紹介している。
A good list of places to get help or learn more about PostgreSQL.
  • タイトルは「Where to Get Postgres Help Online?」。
  • 上記のEditorのコメントとタイトルにある通り、筆者がPostgreSQLに関するヘルプを受けられる先のリストを共有している。
  • Twitterの存在を感じる「Of course there is always twitter」のコメント。簡潔に質問するのに良い場所。
If you’re running Java applications then you need to understand how to get metrics from the JVM. This post describes the critical JVM metrics available via JMX like memory usage, garbage collection, and thread counts.
  • タイトルは「Key JVM Metrics to Monitor for Peak Java Application Performance」。
  • タイトル通り、パフォーマンスと安定性に関心がある場合に監視する必要がある主要なJava Virtual Machine(JVM)メトリックを解説している。

Tools

A set of best practices for AWS Serverless applications available for testing your infrastructure as code as plugins for cfn-lint and tflint.
  • 推奨される方法に照らしてインフラストラクチャをコードテンプレートとして検証するためのルールをまとめたものである「Serverless Rules」のGitHubページ。

SRE Weekly Issue #274 June 13th, 2021

Articles

Chicken Soup for the SLO

The last section suggests selling SLOs to executives by likening them to OKRs or KPIs.

Austin Parker — Devops.com

  • コミュニケーションを切り口にSLOのポイント、良さについて解説している。
How Lowe’s leverages Google SRE practices

Lowe’s is a home improvement retailer in North America. I often find it fascinating when I learn that a company that’s not seen as being in the tech-sector has a robust SRE practice.

Vivek Balivada and Rahul Mohan Kola Kandy — Lowe’s

  • Lowe’s社でGoogle社のSREフレームワークを採用し、Google Cloudとのパートナーシップを活用することで、サポートできるリリースの数を増やした方法を以下4つのポイントを共有している。
    1. Automate away toil
    2. Engineer alignment through roadmaps
    3. Adopt one-touch releases
    4. Embrace capacity planning
Incident writeup as sociological storytelling

The hallmark of sociological storytelling is if it can encourage us to put ourselves in the place of any character, not just the main hero/heroine, and imagine ourselves making similar choices.

Lorin Hochstein

  • 上記のEditorのコメント通り、インシデントの社会学的なstorytellingにより各人が登場人物の立場で考えることができる点を解説している。
DevOps & Autism Care

This is brilliant: they apply DevOps and SRE practices to the challenging work of raising two autistic children.

Zac Nickens — USENIX ;login:

  • 「DevOpsをそこに適用するのか!?」という驚きが大きかったし、継続的な取り組みを行うために、こうした軸を持つことの大切さを改めて感じた。
  • 上手くいかないこと、感情的になりそうなことを受け入れていくためにも、こうした原則を持っていると良さそう。
Implementing ChatOps into our Incident Management Procedure

I especially like how their bot automatically pages reinforcements after folks have been on an incident for long enough to become fatigued.

Daniella Niyonkuru

  • 2018年2月13日の記事。Shopify社でのインシデント管理の概要、インシデント中のさまざまな役割の責任、およびチャットボットがチームをサポートするためにどのように機能するかを解説している。
  • 記事の末尾に筆者の「2017 talk at SREcon」の動画が埋め込まれている。
The MTTR that matters

Rather than measuring Mean Time To Recovery for incidents, let’s track our Mean Time To Retrospective.

Robert Ross — FireHydrant

  • MTTRを一般的な「Mean Time To Recover」ではなく、最後のRを変えた「Mean Time To Retrospective」にすることで、チームをさらに前進させられることを以下のポイントで解説している。
    • What can we measure then?
    • Wait, what?
    • So, why Mean Time To Retro?
    • How to calculate Mean Time To Retro
    • The value of a retro gap average
    • Change what you’re measuring

Outages

  • Fastly
    Fastly had a global outage of their CDN service, with many 5xx errors for around 40 minutes and diminished cache hit ratios following after. Many customers of Fastly experienced degradation, notably including Amazon, Reddit, and GitHub, among many others. Fastly posted a summary shortly after the incident, describing a latent bug that was triggered by a customer’s (valid) configuration change. Full disclosure: Fastly is my employer.
  • Salesforce
  • Facebook, Instagram, and WhatsApp

上記各社の障害情報


KubeWeekly #266←Juneteenthで祝日のため、KubeWeeklyはお休み。


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

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

では、また。

Bye now!!

Yoshiki Fujiwara