リーダーとマネージャの違い - ツナワタリマイライフ
最近見たいくつかのツイートが自分の考えとちょっとズレがあったので考えてみる。 僕はリーダーシップを発揮することとマネジメントを行うことは別な仕事だと考えています。勿論、両方を同時に行える人が素晴らしい成果をだせるだろうという事に異論はありませんが、マネジメント業務からリーダーシップの発揮を少し外してはどうだろうかと考えています。— 太一 (@ryushi) April 16, 2023 例えば、チームビジョンを策定し、それに向かってメンバーを鼓舞するといったような仕事は、マネジメント業務から外してもいいんじゃないか？というのが僕の意見です。— 太一 (@ryushi) April 16, 2023 見つけられなかったのだけど、 マネジメントは欠けている要素を増やす、リーダーは目標を決めてチームを前に進める、やることを減らす、なので本来真逆である、みたいなやつ。 こういうのもか。 組織を成功
SRE とプロダクト開発の EM を兼務して半年経った - ツナワタリマイライフ
3ヶ月前の振り返り https://blog.chaspy.me/entry/2022/12/24/120000 いろいろキツかったがなんとか走り切れたかな、というそんな感じ。うまくいかない時期もあったが、周囲にサポートしてもらいながら、少しずつ前に進むことはできたと思う。 SRE ややハードになりそうな状況ではあったが、なんとか乗り越えられたと思う。メンバー1人1人の自立性と技術力のおかげだと思う。 11月に1人、2月に1人入社し、メンバーは7人になったところで採用を止めることができた。これにより採用活動にかけていた時間を使わなくなったのは大きい。 新しく入った2名についても順調に立ち上がっていると判断していて、1on1は細かめにやっているものの、マネージャーというよりはメンターとそれを受け入れるチームが正しく機能していたことが大きいと思う。 後半の Q4はリーダーが他のチームに留学した
2020-07-05 SREに関する雑談 bosyu#4 ECS + Fargate 構成におけるログの問題と IaC について - ツナワタリマイライフ
こういう bosyu をしています！ bosyu.me 背景 Frontend / Backend をやる Engineer の方が、副業でインフラを含めすべて1人で構築するシーンで苦労しているので壁打ち相手になってほしい 特にインフラに苦手意識があるため、どうやってキャッチアップしていくかを悩んでいる ということで、このあたりの勘所はなかなか経験ないと厳しいところだと思うので、壁になるだけでも十分貢献できたようです。 いくつかトピックを紹介します。 実践 Terraform をみて動かしてみるが、コピペ Terraform エンジニアになってしまっている 実践 Terraform すばらしいですよね。 実践Terraform AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）) 作者:野村 友規発売日: 2019/09/20メディア: Ki
育ってから対処する問題と、育つ前に対処したいかもしれない問題 - ツナワタリマイライフ
問題には2種類あることに気づいた。 育ってから対処する問題 1つは、実際に何か困っていることがあって、解決したい課題があるという問題。そしてそれはあるひとにとって関心が高く、かつ他のひとからもある程度理解できるような問題。 たいていの問題はこれに分類される。これは時間をかければかけるほど、勝手に問題の問題度があがってくるので、それがあがった適当なタイミングで対処すれば良い。 明らかに困っているので、やる理由も明確だし、困っている度合いによって優先度も勝手につくので楽だ。見積もりをする必要もない。 こちらを仮に育ってから対処する問題と呼ぼう。別に育って「困って」も取り返しのつかないというほどでもないので、ちょっとは大変な思いはするだろうが、適切なタイミングで摘み取れば良いのでシンプルだ。 育つ前に対処したいかもしれない問題 もう1つは、現在は実際に困っているわけではないし、それが本当に問題か
SRE チームで Engineering Manager になって二ヶ月経っての心境など - ツナワタリマイライフ
この記事は前任 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人のチーム もともと中途採用をしていた会社でもあり、自走可能なメンバーで構成されて
AWS RDS の Max Connections を Prometheus 形式で Export する OSS を作って current connections / max connections 比率でアラートを出す - ツナワタリマイライフ
作った。 github.com これは何か RDS の設定値、max_connections は PostgreSQL、MySQL ともにある。接続数がこの数値を超えるとエラーとなるため、この数値を超えないように監視できることが望ましい。 しかしこの max_connections、RDS の parameter group の value の1つであり、cloudwatch metrc に存在しない。そのため Datadog Integration でも取ることができない。 というわけでそれを取って Prometheus 形式で Export することにした。 なお、現在の接続数 database_connections は取れる。 docs.datadoghq.com これとの比で、例えば9割になったら Alert みたいなことができるようになって便利。 また、新規サービスリリース前に
#srefm Production Readiness 会まとめ - ツナワタリマイライフ
はい。こちらのイベントのまとめをしていきます！ t.co 今回はゲストに @koudaiii さんと _a0i さんをお招きして、Application や Infrastructure / Platform の Production Readiness について語りました！ お二人を選んだ理由としては、坂部さんの場合は Production Ready に関するアウトプットがすでにあったということで、すぐに打診しました。aoi さんのほうはサイボウズさんとかどうだろうねということで思いついて声かけました！お二人とも快諾していただき感謝です。 期待とか chaspy の所感とか hackmd のほうにざーっと書いたやつ。 chaspy の所感 Production Readiness Checklist とても良いもので、やってよかった。 SRE の負担を最小限にしつつ、Developer
IaC Maturity Model と学習ステップ #srefm - ツナワタリマイライフ
はじめに 先日、ノリと勢いで企画した SRE.fm を行い、ゆるふわに Terraform や IaC の話をしました。 sre-fm.connpass.com 実際にやってみて、質問への回答を行う中で、IaC に関わるひとたちのマジョリティと自分たちには大きな隔たりがあるような感覚を持ちました。そういった中で、質問の1点1点に答えるというよりも、大局的な理解であったり、その本質的な要素であったり、段階に分けた学習ステップ等を言語化することが必要なのではないか、と（その後の二次会で）たどり着きました。 「IaC は当たり前になった」というのは Infra Study Meetup #1「Infrastructure as Code」 での Mizzy さんの言葉で、これに関しては大きく同意するものの、この「当たり前」は「誰でもしている状態になった」「できていないのはありえない」というもので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
