はじめに この記事はMERPAY TECH OPENNESS MONTHの4日目の記事です。 こんにちは。株式会社メルペイで backendエンジニアをしている cowsys です。 プロダクト/システムで発生した「問題」をいかにして解決するか。 いかに素早く原因を特定/解消し、正常化させるか。 上記のような「問題の調査と対応」は、backendエンジニアとして持ち続けている、大きなテーマの一つとしてあります。 メルペイの開発で初めてDatadogを利用してみて、このテーマが、大きく前進したような手応えを感じました。 ここでは最もインパクトのあった変化に絞り、どのような変化が起き、それは何によってもたらされたのか。 Datadogの導入事例として、また「問題の調査と対応」を考えるエンジニアとして、感じたこと、考えたことをお伝えできればと思います。 目次 はじめに 目次 利用しているData

ダウンロード版で読みました。 booth.pm 本の情報 項目 情報 ページ数 144P 章数 全22章 著者 @tmknomさん 全体的な感想 大事なのはTerraformの使い方というよりAWSのリソースを正しく構成して関連する全てのリソースの存在を明確に意識する力だと思いました。難しい。 最後の章に書いてある参考文献もとても素晴らしくて、SREとしてやっていきたいなら必要な知識が書かれている本ばかりですのでぼちぼち拾って読んでいきたいです。 ↓読んでいて心に残った言葉 Terraform で試行錯誤するときには、ケチケチせずにそれなりのインスタンスタイプを使用しましょう。時は金なりです。 こんな人におすすめ サーバーサイドは書けるけどWebインフラはちょっとあんまりって人は読んでとてもためになると思います。 この本を買った理由 Terafformを1から自分で書くという経験をしたこと

どちらも大変素晴らしい記事で、大変よくまとまっていながら主張が入っていて読みごたえのある文だった。それに比べたら、以下の文はまとまりもない駄文だが、それでもどうしてもこの話題には物申したくなる自分がいる。知見と呼べるほどでもないけれど、3年間マイクロサービスのことを考え続けてきた者の率直な感想として、読んでいってもらえたら嬉しい。 tl;drこの記事を通して、僕が結局何が言いたいのかというと、マイクロサービスはもっと開かれたものであってほしいということだ。複数のビジネスをやるならマイクロサービスの考え方を導入する権利があるし、すでにマイクロサービスをやっているなら、マイクロサービスのことを考えるのは基盤チームだけじゃなくてみんなであるべきだ。 マイクロサービスは「やる」か「やらない」かではない前者のdeeeetさんの記事は、全くマイクロサービスを知らない人がぜひ読むべき、本当に良い記事だと

社内でKubernetesハンズオンをやってみたのでおすそ分け。 参加者6人からバンバン出てくる質問に答えながらやって、所要時間4時間ほどでした。 SpeakerDeckにも資料を上げています。 https://speakerdeck.com/ktam1219/yaruze-kuberneteshanzuon (2019/07/11追記) 続編書きました！ -> 今度はあんまりゴツくない！？「わりとゴツいKubernetesハンズオン」そのあとに ハンズオンの目標 Kubernetesとお友達になる イメージを掴む 触ってみる(ローカル・EKS・ちょっとGKE) 構築・運用ができるような気分になる 巷にあふれるKubernetesの記事・スライドが理解できるようになる EKSがメインになっているのは、会社の業務でAWSを使うことが多いからです。 純粋にKubernetesを勉強したいだけな