以下勉強会のメモと感想です。 DIPのSREの活動とこれから(ディップ株式会社　bayashi_ok さん) バイトルなどの求人情報サービスを運営 SREのスタート(小規模、中規模、大規模) 小規模だとはじめやすい DIPは会社規模は大きめ 入社時110人、インフラ8人 規模が拡大してきたのでSREとしての取り組みをはじめた 自動化 - Ansible - 導入の問題(Git, Ansible, コード化メリット) 分からない背景 問題を問題だと気がついていない 気づいていないから学べない よくわからないから変えたくない コード化するメリットを教える 作業の効率性を意識させる 他社事例を教える->メンバーの安心感を得る Git, Ansibleの使い方を何度もレクチャー、丁寧な説明 変更する頻度の高いサーバーから導入 結果、コード化する文化が根付いた 承認フローを確立 作業ミスの軽減、冪等性の担保 リリース作業負荷の軽減 ログの可視化 アラートには出ない404エラーが多数発生 可視化で見えてきたものを元手に組織の連携 速度改善が会社で依頼 Official Google Webmaster Central Blog: Using page speed in mobile search ranking Fastly導入 モバイルサイトUXレポートでカテゴリ単位の総合評価No.1 タップルSREの軌跡と描く未来(株式会社サイバーエージェント　袴田類さん) タップルSREのリーダー DevOpsチームの解散を経験 課題解決型チームだった 負債返却とシステムの更新 コスパのいい課題に重点をおいてやっていた（工数は低いけどインパクトがでかい） 課題解決のインパクトが出しづらくなってしまった ボーナスチャンスを優先的に解決 工数がでかい課題が増えた 足元課題の解決型チームからの脱却 事業目線に立つことが重要 足元課題解決を行いつつ、事業課題を解決 足元課題を極力SLOとして計測可能にする 組織の理想状態の実現に向けて中長期戦力を実行 現状、信頼性担保に振り切れていない SLO アプリケーションメトリクスから作成するSLO 稼働率 サクセスレート レスポンスタイム 組織も抱えるリスク リスクスコア 未実施の障害再発防止策をスコア化 障害対応スキルレベルのSPOF セキュリティー対策 自動化可能作業 CS問い合わせ数 Draw.

会社で@adachin0817にオススメされたのでせっかくなので通勤時間を利用して読んでみることにした。 200Pあまりなのだけど、最近読書力が下がってきていたので、通勤時間だけだと中々読むスピードがあがらず、結局1週間くらいかかったと思う。 しかし、内容はとても素晴らしく、何年も前に書かれたものだけど今でも活きるものばかりだった。 電車内で読んだのでほとんどメモが取れなかったが、取れた範囲で感想を書いていってみる。 1人で仕事をするほうがリスクが高いということだ。誰かと一緒に仕事をすると、アイデアを盗まれたりバカにされたりしないかと不安になるかもしれないが、間違ったことをして時間をムダにすることを不安に思うべきだ。 仕事は常にオープンにし、みんなにみてもらって、より良いやり方やコードがあれば教え合う。 まずそうなことがあればストップをかける。 確かにそうすれば、ポジティブなこともネガティブなことも、常に改善して良い方向に進んでいくはず。 一人でやることが悪いわけではないが、チームでやっているのであれば、チームみんなで協力しあえたほうが良いのはその通り。 HRT humility謙虚 respect尊敬 trust信頼 これは本当に大事。 結局、仕事は対人間同士のやり取りが多くを占める。相手を蔑んでマウントを取り合うようなことをしていれば、どんどん人々はリタイアしていって、そこに残るのは一人だけになるのだと思う。 そうならないように、日々お互いを信頼し、尊敬し、常に謙虚であることで、チームプレイが加速していくのだろう。 きっと夫婦間でも大事なのだろうなと、最近ひしひしと感じてます笑 他の人があなた（とプロジェクト！）に恩恵をもたらしてくれると心から信頼し、自分がバカだと思わないことである。 君は君の書いたコードではない。 出したプルリクエストに厳しいコメントが返ってくると、ショックだったりすると思う。 レビュワーだったら、HRTを大事にして、コメントの文言を選んで書くべきだろうし、レビュイーだったら、そのコメントに一喜一憂するのは非生産的だ。 コメントに書いてもらったことはポジティブに捉えて、プラスになるよう改善していくと良さそう。 リーダーシップパターン 多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある 長く勤めているとわかってくるのだろうけど、とある事象について詳しいのはAさん！みたいなのを知っておくと、トラブルがあったときや、新しい何かをはじめた際に物事が円滑に進みやすくなるというのは良くわかる。 今のチームのリーダーも、これは○○さんが詳しいということを教えてくれるので、ありがたいし、こうゆう情報をインプットしておくのも大事なんだろう。 同じ失敗を繰り返さない限り、失敗によって多くのことをすばやく学べる ポストモーテム これはSRE本でも取り上げられていたGoogleらしい取り組み。 失敗から学ばないのは悪い習慣だけど、失敗することが悪いわけじゃない。 失敗した結果、得られることは膨大な知識と経験になるはずなので、ちゃんと振り返る。 失敗から学ぶというスタンスで振り返りを行うのはめちゃくちゃ良い取り組みなので、個人だけでもやろうと思うし、チームでもやっていきたい。 4章 有害な人に対処する 排除するなはあくまでも振る舞いであり、特定の個人ではない。 なかなかインパクトのある言葉だけど、余程チームに悪影響を与えていてみんなが辟易していない限り、その人を排除したいとは到底思わないだろう。 だからこそ、それを指摘するのに、その人を否定するような言動は避けるべきというのはとても同意出来る。 その人に改善を促すように努めることで、もしかしたらその人は気がついていないかもしれないし、言葉で伝えることで自分の考えも伝わりやすいかもしれない。 ほかにも、たくさん良い言葉があったし、「そうそうそれそれ〜」とつい共感してばかりだった。 まずは、今日メモしたことを念頭におきつつ、日々実践していきたい。 ちなみに、人に比べて技術書の読書量が多くないのだけど、個人的にはとても響いた本の1つだった。 まだ読んだことが無い方がいればオススメです。 Team Geek ―Googleのギークたちはいかにしてチームを作るのか

リーダーの金澤さんがSRE Lounge #4というイベントで登壇することになったので参加してきた。 https://sre-lounge.connpass.com/event/91566/ SRE Loungeはstudistの@katsuhisa__さんが運営されているSREイベントで、すでに3回クローズドで開催されたようで今回はオープンなイベントとなった。 なお、今回会場提供はindeedさんでindeedさんと言えばCMのイメージが先行して、それ以外の会社概要は知らなかったのだけど、オフィスはパーティションに区切られていたり、ビリヤード台や卓球台のある広いスペースもあったり、始まる前には英語での会話がそこらで繰り広げられていたりと外資系らしい綺麗なオフィスだった。 そんなindeedさんのSREチームの大野さんが発表のトップバッターだった。 いきなり資料が全部英語で細かい箇所はわからない所もあったが、indeedさんのサービスやOpsからSREへの遷移などわかりやすく発表されていた。 意外にもオンプレばかりらしく、印象的だったのは世界をまたいでの運用の話が中心だったので、スケール感がでかいと感じた。 例えば、オンコール対応も世界でタイムゾーンが違うのでビジネスアワーの場所が対応を行うという話だったり、各地にあるDC間で障害があったら切り離せるようにしていたりして内容にインパクトがあった。 他にも開発者がオンコール対応をする話だったり、社内ツール内製の話だったり、とても興味深い内容ばかりだった。 2人目の発表は金澤さんの話だった。 過去の経緯と現在の取り組み、これからの取組みの話だったので過去経緯のツラミなんかは結構響いてたように思う。 金澤さんはネットワークからアプリケーション、DBまで幅広い知識を持ち合わせているので、その辺は特にインフラレイヤーを離れた部分もあって聞いている側としては新鮮だったのではと思う。 最後3人目は元？Studyplusの満足さんだった。 小さな会社がどうやってインフラをまとめていったかという、まさにスタートアップならではの話が聞けてとても身に沁みた。 特に、インフラエンジニアは普段なにをやっているかが伝わりづらいので、ロールマップを共有して、いつ頃なにをやるというのを伝えていくというのは特に感心した。 中々インフラのことをアプリやデザイナーの人に話してもよくわからないだろうなという気持ちが先行してしまいがちだけど、そんなことを考えずに積極的に共有していくのは大事だなと思った。 時間の関係上、懇親会は参加できなかったが大変有意義な時間だった。 次回開催される際は是非また参加したいし、自分も発表できるようなネタができるように日々改善していきたい。 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

2018.2.20（火）渋谷TechPlayで開催された「事業の多角化を支えたランサーズ的SRE術」に参加してきた。 以下はその時のメモ。 CTO横井さん Lancersの概要（最近資金調達したよ、160人くらいいるよ、働き方の改革を進めてるよ） 2年くらい前から新しいサービス提供をはじめた。quantというサービス、デジタルマーケティング、Adテクノロジー pook C to C サービス。家事代行とか。オフラインのサービス。 地方創生事業（奄美大島とか）、仕事がないのでクラウドソーシングで仕事創出。→エンジニアのさすらいワークとしても実施している。リモートワークの採用。 エンジニアは30名程度。 SREは4名。 SREチームにしたから何かが変わったことはない。 平塚さん ECSの話 去年の10月まではSREは2人 今は4人 大きく4つのサービス Lancers/Quant,TOP/Pook,Sub 20Services 複数のプログラム（CakePHP,Go,Rails） Terraform,ANSIBLEで管理。 開発環境はDocker,アプリケーションエンジニアもDocker。 ECSだったらDockerそのままもっていけるのでは？ 環境はTerraformとECS-CLI. ECS-CLIはECSのみ管理。VPSとかSGとかは Terraform. なぜECS？→ プロトタイプ環境構築のスピード感。 構成管理が実態と剥離してきた OSSのバージョンアップ→ ゴミファイルが残ってしまう->きれいにした状態で再作成しなおせる 手作業をやめる k8sを選択していない理由->AWSのオーケストレーションはECS一択なのでECS. The Twelve-Factor App を参考に（https://12factor.net/ja/） サービス ユーザー -> ALB -> Nginx -> ALB -> Admin,API,Job,Batch -> Redis,RDS ユーザー -> CloudFront -> S3 ポートマッピング（動的ポートマッピング） Dockerfileはシンプルにしている リリースツールはECS-CLI。ECSでTask Defitnition,Service Definitionで定義した情報をもとに構成する。 Pook は Rails.