はてなブックマーク

3ヶ月前の振り返り https://blog.chaspy.me/entry/2022/12/24/120000 いろいろキツかったがなんとか走り切れたかな、というそんな感じ。うまくいかない時期もあったが、周囲にサポートしてもらいながら、少しずつ前に進むことはできたと思う。 SRE ややハードになりそうな状況ではあったが、なんとか乗り越えられたと思う。メンバー1人1人の自立性と技術力のおかげだと思う。 11月に1人、2月に1人入社し、メンバーは7人になったところで採用を止めることができた。これにより採用活動にかけていた時間を使わなくなったのは大きい。 新しく入った2名についても順調に立ち上がっていると判断していて、1on1は細かめにやっているものの、マネージャーというよりはメンターとそれを受け入れるチームが正しく機能していたことが大きいと思う。 後半の Q4はリーダーが他のチームに留学した

なった。10月から。 ちょうど1年前、元々所属していた SRE Team の EM になった。1年間、SRE Team のマネジメントをしつつ、SRE Team が活躍できる機会を提供し続けられるように、どちらかというとユーザーでもある開発チーム、あるいは開発部全体のことに目を向けていた。開発チームがチャレンジングなことをしようとすればするほど、SRE Team もよりチャレンジングな課題に挑戦できるはず。現状と未来、両方を見つめてやれることをやってきた。 SRE Team は開発チームが作るシステムが安定稼働できるよう、開発チーム自体のシステムの Controlability を高めることや、それに関連する開発者生産性を高めることをミッションにしている。 つまり、ユーザは開発者である。Platform もプロダクトとして考えると、ユーザのことをよく知る必要があるし、ユーザーからフィードバ

この記事は前任 EM の yuya-takeyama の記事へのアンサーソングであり、 blog.yuyat.jp Engineering Manager Advent Calendar 2021 その2 2日目の記事として寄稿します。 qiita.com 背景 僕は引用記事の SRE チームの Software Enginner でした。ひょんなことから前任が別のミッションを担うことになり、このチームの後任としてどうか、となり 2021年10月より同チームの Engineering Manager をやっています。 以下、引用したりしなかったりしてこの2ヶ月の心境などを語っていきます。 Engineering Manager として置かれている状況 先ほど言った経緯に引き続き、情報的な話でいうと 自分含め7人のチーム もともと中途採用をしていた会社でもあり、自走可能なメンバーで構成されて

ずいぶん公開に時間が経ってしまった。6/4 か。。。特に出せなかった理由はない。より「ちゃんとした」形で出したいと思っていたが、そんな日はこないので当時のまま公開する。 WSA 研に初参加し、はじめて自分の身の回りの仕事、SRE の関心対象に対して計測を行なった。当時は本当に手探りであったが、この時泥臭くデータを取り、考察したことが2ヶ月後の今に確実に繋がっている。貴重な機会をくれた WSA研のメンバーに感謝したい。 当日は参加者からたくさんフィードバックをもらえた。その時いただいた意見は今に活きており、より実務に生かすことができている。 修士卒業以来久しぶりに「研究」っぽいことをしたが新鮮で楽しかった。ビジネスと研究、行ったり来たりするのいいかもな、と思った。 本資料は第8回WebSystemArchitecture研究会の予稿です。 以下が当日使ったスライドです。 背景 Site Re

職業ソフトウェアエンジニアを7年+ やってきて、いわゆる新卒、ジュニアからキャリアをスタートし、今は Site Reliability Engineering 領域で Lead をしている。 こうした中で、自分自身のことを振り返ると、ソフトウェアエンジニアリングとは自己認知との戦いではないか、と思う。 自分自身、自分の認知の歪みでパフォーマンスが著しく出なかった経験が何度もあった。そして認知の矯正によってパフォーマンスが急に出るようになった経験、その両方がある。 昨日たまたま、エンジニアリングと認知について話す機会があったのでついでに記録しておく。 ソフトウェアエンジニアリングに対する認知 ソフトウェアエンジニアリング、システムプログラミング、なんでもいいが、こういったものを取り扱ってビジネス価値を発揮している我々にとって、機械の上で動く、なんらかの入力を通じて動く何某は当然目に見えないし

はい。こちらのイベントのまとめをしていきます！ t.co 今回はゲストに @koudaiii さんと _a0i さんをお招きして、Application や Infrastructure / Platform の Production Readiness について語りました！ お二人を選んだ理由としては、坂部さんの場合は Production Ready に関するアウトプットがすでにあったということで、すぐに打診しました。aoi さんのほうはサイボウズさんとかどうだろうねということで思いついて声かけました！お二人とも快諾していただき感謝です。 期待とか chaspy の所感とか hackmd のほうにざーっと書いたやつ。 chaspy の所感 Production Readiness Checklist とても良いもので、やってよかった。 SRE の負担を最小限にしつつ、Developer

はじめに 先日、ノリと勢いで企画した SRE.fm を行い、ゆるふわに Terraform や IaC の話をしました。 sre-fm.connpass.com 実際にやってみて、質問への回答を行う中で、IaC に関わるひとたちのマジョリティと自分たちには大きな隔たりがあるような感覚を持ちました。そういった中で、質問の1点1点に答えるというよりも、大局的な理解であったり、その本質的な要素であったり、段階に分けた学習ステップ等を言語化することが必要なのではないか、と（その後の二次会で）たどり着きました。 「IaC は当たり前になった」というのは Infra Study Meetup #1「Infrastructure as Code」 での Mizzy さんの言葉で、これに関しては大きく同意するものの、この「当たり前」は「誰でもしている状態になった」「できていないのはありえない」というもので

弊社には以前 Shadow Proxy というものがいた。 qiita.com 当時のモチベーションとして Database への Index 追加等をぶつけでなく事前にやりたい、ということだった。現状は Production database の Snapshot から Develop database を毎晩リストアしており、事前にそちらで実行するようにしている。 2020年の今やるなら Envoy かな、と。 で、ここでモチベーションとしてあげている負荷テストとは特に、Database の Migration のことを考えている。 現状 EC2 上に MongoDB をセルフホストしている。そのためインスタンスのスケールアップが必要なときにはいろいろあって1日ほどかかる。マネージドサービスの Atlas にすればスケールアップも容易で早くなるし、パフォーマンスに関する分析も提供してく

してきた。 sre-next.dev SRE Lounge の運営メンバーで、やろーぜ、と手探りではじめた、日本ではじめての SRE のカンファレンスが無事開催された。 やろーぜ、日本でいちばんのSREのカンファレンス、と雑に言い始めたのが去年の4月頃だったかナァ— 🤔 (@chaspy_) 2020年1月25日 運営のコアスタッフとして 主にコンテンツという点で、CFP の選定のリードを行いました。 外から見ると非常に楽しそうには見えますが、やってみるとかなりしんどかったです。 選定に関わった7人のコアスタッフのそれぞれの意見を。正解も基準もない中で、基準を作りながら、有限の枠数に納めなければなりません。 SRE Lounge への信頼もあったおかげで、たくさんの Proposal が集まり、非常にレベルの高い選定となり、嬉しい悲鳴でした。 ちなみに自分も Proposal を出したん

はじめに 現職では Application は すべて Kubernetes 上で動いている。その場合、インターネットからの通信経路は以下のようになる。 Internet -> Reverse Proxy(Nginx) -> Service Router(Nginx) -> Kubernetes Service -> Pod で、後半の Service Router から先が Kubernetes Cluster となっている。Type: LoadBalancer で 受けたあと、forwarding して service-router と呼んでいる Nginx に飛ばしている。 現状、一部で Microservices が動いていたり、Distributed Monolith を Microservices に切ろうとしていたりするが、Service Router 以降の、Pod（App

はじめに 開催しました！ sre-lounge.connpass.com SRE Loungeという、各社SREが取組を共有する、プレゼンテーションメインの勉強会があります。これはこれで貴重な知見がたくさんあるのですが、やはり全員参加で、相互交流ができる会も欲しくなってしまいました。また、SREといっても扱う範囲は非常に多岐に渡るため、特定のテーマにしぼって語り合う会をやりたい！と思い、言い出しっぺに法則で立ち上げました。 テーマ選定 SRE Lounge Slackでアンケートを取った上位2テーマを選択しました。 (Public Chennelのものなので特にふせずにそのまま載せてます） 項目の元ネタはSRE 1st Book / Workbookから僕が適当にかいつまんだものです。 2テーマじゃなくて1テーマでもいいんじゃないか、と迷いましたが、実験的な会だったので読めなかったのと、幸

はじめに でましたね。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者: Mike Julian,松浦隼人出版社/メーカー: オライリージャパン発売日: 2019/01/17メディア: 単行本（ソフトカバー）この商品を含むブログを見る 本当に良い本です。「監視とはなんぞや」からはじまり、「監視はこうやるな」「監視はこうやれ」という思想が最初の3章までに詰まってます。最初の3章までは開発者すべてのひとが読んだらいいんじゃないかな。それ以降は必要なところをおのおのがつまみ食いしていけばいいと思う。SREになる前に読みたかった本です。（原著は出てたわけだけどね） 本自体の解説はいろんなひとがレビューしてそう（出遅れた！）のでそちらを！翻訳者の松浦さん、付録を執筆されたsongmuさんの記事含めてご紹介。 書評「入門 監視」雰囲気で監視をやっているすべての人にオススメ ｜ Dev

はじめに 読んだ。 GitLab実践ガイド (impress top gear) 作者: 北山晋吾出版社/メーカー: インプレス発売日: 2018/02/01メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る Git大好きエンジニアで、もちろんGitLabも仕事で愛用してますし、もう社内のGitLabなしでは僕は仕事できません(笑) 仕事のすべてをGitLabにおいてるので。。。まぁlocalでは作業できるけど。。。 そんなGitLab大好きマン、この書籍出るっていうのでまぁまず買うよね。 軽く内容をさらいつつ、気になる点はgitlab.comで試してみる。 第1章 GitLabが目指す開発スタイル まずはプロダクトの思想から。大事ですよね。 DevOpsの考えを前提とした上で、ConvDev(Conversational Development)というスタイルを推奨

はじめに 作った！バーン！ http://favsearch.chaspy.me リポジトリ github.com 今回もqsと同じく仲良し@kamontiaと作りました。 なぜ作ったのか favってひとによって使い方違うと思う、ラフにハート送るために使ってるひともいれば、ブックマークがわりに（まぁ今ブックマークって機能あるっぽいけど）つかってる人もいると思う。で、あー過去のfavでなんかあったなーって思い出せないとか、検索したいなーっていうシーンが何度かあって、作った。 ただの検索じゃ面白くない、みんな大好きpecoよろしくインクリメンタルサーチしたいよね。 技術スタック ってほど重厚なものはなくて、Twitter API使ってfav取得して絞るだけの薄いアプリです。 sinatraのappをherokuに載せています。webアプリ作るのにsinatraは最高便利。frontendはVu

Docker/Kubernetes 実践コンテナ開発入門 作者: 山田明憲出版社/メーカー: 技術評論社発売日: 2018/08/25メディア: 単行本（ソフトカバー）この商品を含むブログを見る 読んだ。雑に記録。 1-3章はDockerについて。ふむふむと軽く目を通した感じ。 ところでdocker containerコマンドって今まで使ったことなかったです。 で、4章と5章がSwarm。これまで使ったことなかった。 docker in dockerで、swarmのmanagerとnodeとregistryをそれぞれdockerの上に作って、そこでいろいろ遊ぶのはすごいうまくやってるデモだなぁと思った。 でも正直作者もいうとおりswarmはkubernetesにつなぐための布石でしかなくて、一応podだとかの概念の理解の助けにはなるとはいえ、面倒な部分、本番運用に耐えない部分を、そうそれを

はじめに 読んだ。 tatsu-zine.com ずいぶん前に買っていて、途中までやって放置していた。3時間ほどで読み通せた。 モチベーションとしては、「プロセス」って正直よくわかってないな、と思ったから。そのあたりをちゃんと学ぼうと思った。 コンテナを使うことが当たり前になった今、コンテナはプロセスだーって言っても、そもそもプロセスって何なのか。こういうOSレイヤーの知識は長く活きるので、学習効果が高いと思い、最近はこのあたりを学んでいきたいと思っている。 感想 プロセスとはUNIX上の全てのプログラムの実行単位としての抽象概念であることがわかった。 この本はUNIXプロセスの様々な挙動をRubyプログラムから試す本である。さくさく進めて気持ちいいし、著者のユーモアの効いた表現が読んでいて楽しい。ただその特性からRubyプログラムを深く理解するものでも、UNIXプロセスの詳細を理解できる

はじめに 18/06/20付けで新卒入社した富士通株式会社を退職しました。丸4年と3ヶ月働きました。とてもいい職場でしたが、ありあまる僕のチャレンジ精神により飛び出すことにしました。振り返っておこうと思います。 何をしていたか Public Cloud K5のIaaS開発を主にしていました。内部ではOpenStackを使っていたので、OpenStackのIaaSコンポーネント（nova, cinder, glance, keystone）＋オーケストレーションのheatを見ていました。IaaSということで、OpenStackで抽象化されたその裏側のサーバ、ネットワーク、ストレージという物理リソースと、それらを仮想化する仕組みについても学びました。 ascii.jp なぜ転職するのか 理由はいろいろありますが、ポジティブな理由です。別の環境で新しいことがしたくなった、ということと、もっとソフ

はじめに 読んだ。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者: 広木大地出版社/メーカー: 技術評論社発売日: 2018/02/22メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 一周普通に読んだあと、内容を咀嚼しながら読み返してメモしていたらかなり時間がかかってしまった。 本当はメモ＋自分の考えみたいなのをブログに書きたかったのだけど、もはやほとんど引用で引用の範囲超えるんじゃねぇかって感じなのでブログには自分の感想＋サマリを書く。読書メモはgistにあげた。 エンジニアリング組織論への招待.md · GitHub （エンジニアリング組織論への招待の）はじめに 僕は、この本の主張とまんま一緒というわけではないけれど、「ソフトウェア開発とは不安との戦いだ」ということを考えていた。 blog.chaspy.me まぁ

はじめに 読んだ。 Effective DevOps ―4本柱による持続可能な組織文化の育て方 作者: Jennifer Davis,Ryn Daniels,吉羽龍太郎,長尾高弘出版社/メーカー: オライリージャパン発売日: 2018/03/24メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る DevOpsというワードの定義が曖昧なまま数年経過し、各組織ごとに理解したDevOpsで"なんとなく"やっている。僕としてはもうDevOpsという言葉を使うのもちょっと避けていたぐらい。「今時はデブオプだー」っていう声を聴くと耳を塞ぎたくなる。 とはいえ、じゃあ自分はDevOpsを正確に理解しているのか？そもそも正確な理解なんてあるのか？自分なりの答えはあるのか？と言われるとNoで、本書はDevOpsの定義について、人間的なアプローチで迫った最初の本だと思う。 実際のところ、

はじめに 参加した。 increments.connpass.com Qiitaにはいつもお世話になっているので、参加した。 LTした LT枠余ってそうだったので突発でLTした。色といい内容といいQiitaへの忖度みを多分に含んでいる。 speakerdeck.com 発表内容に関して、（いろんな理由で）聞けてよかったというフィードバックを得られて嬉しかった。ちゃんとOrganizationアピールもしたよ。 他の方のLT PANQ www.panq.jphttp://www.panq.jp speakerdeck.com qiitaの記事のうち、他のqiita記事に参照されている記事を 検索するサービスを作ったという話。 APIでは被link数は取れないらしい、クローリングされるよりはAPI出したほうがいいんだけど、悩ましいようでした。 qiita自身の検索の話が少し話題になりました。

はじめに 読み終わりました。 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司出版社/メーカー: オライリージャパン発売日: 2017/08/12メディア: 単行本（ソフトカバー）この商品を含むブログを見る 英語の原著が出た時点でkindleで購入していたにも関わらず読み通せなくて、その後英語版は無料公開されました。 Google - Site Reliability Engineering ほどなくして翻訳版が出て、読まないわけにはいくまいと購入。2ヶ月ほどずっとリュックやバッグにいれて持ち歩いていました。重かった。。。 SRE、信頼性エンジニア

はじめに 構成管理ツールだとか。Infrastructure as Codeとか、大好きなんですけど、どうもここ数年Dockerの勢いが止まりません。もう構成をコードで書くんじゃなくてコンテナのほうが楽なんじゃないって時代、目の前に来てる気がする。 何年遅れてんだって感じでようやく仕事でもAnsibleを使い始めましたが、これはこれで大事だけどDockerは使えないとマズい。なぜかそんな空気を感じるので触っときます。 vagrantでdeploy Macにも入れられるとは思いますが、まずはVM上に実行します。 記事最後にgithubへのリンク貼ります。 ansibleのplaybook、とりあえずyumでいれる。 --- - hosts: all become: yes tasks: - name: install yum package yum: name=docker state=pr

はじめに 仕事の話ですが、自分が今何の仕事持ってるのかっていうのをtxt、もしくはmarkdownでメモしています。リーダーがまわってない大変多くの仕事を抱えているので、進捗状況を毎日リーダーに日報としてメール出してるんですが、自分で見てもテキストで書かれたタスク表見難くて仕方ないので、何か改善する方法がないかと思いました。 で、日報って何が知りたいかって前日との差分だと思うんですよ。それが簡単に分かれば。。。gitlab立ててばいいのでは、と思い立てました。仕事しろ？改善活動も立派な仕事！ VMを自由に作れる環境があるので、そこにCentOS6.7をいれて、gitlabをいれました。 gitlabのインストール 会社内の話なので、記録がないので記憶で書きます。（やっぱ会社でやったことは会社で記事書きたいわ。。。） ほぼほぼ公式サイトの手順でできるはず。 about.gitlab.com

はじめに AtomいいよAtom。エディタです。設定方法を以前書きました。 take-she12.hatenablog.com ここで入れてるmarkdown-tocのお話です。 toc(table of contents)、つまり目次を見出しから自動生成してくれるプラグイン。 haroopadだと[TOC]と書くだけで生成してくれてナイスなんですが、まぁatomでも同様なことが実現できます。 こういうやつですね。 ただ、なぜか生成されたhtmlファイル、リンクしてくれません。それが一番欲しいのに！ markdown-tocの設定 何はともあれ公式ドキュメントを見ましょう。（最近こういう癖ついてきてうれしい） atom.io Features Auto linking via anchor tags, e.g. # A 1 → #a-1 Depth control [1-6] with d