pleroma.chroju.dev

pleroma.chroju.dev

chroju | @[email protected]

お一人様Pleromaサーバ pleroma.chroju.dev の管理者。
普段はSREチームのエンジニアリングマネージャーとして働いています。

発言は pleroma.chroju.dev/users/chroju/feed.atom からRSSで購読もできます。

Terraformのディレクトリをnetwork、DBのようなレイヤーごとで分割する手法、最近よく聴く気がする。 #srekaigi_a #srekaigi

Datadogのorganization横断での可視化、わりと需要あると思うんだけど、意外と公式提供がない機能。 #srekaigi_a #srekaigi

AWSにおける横断的なログ分析とコストの管理 #srekaigi_a #srekaigi

チームの目的に対して視野広くアプローチしていくのと、1チームの責務として広くなりすぎていないかとのバランス、組織設計難しいよなぁ。 #srekaigi_hall #srekaigi

SREの普及拡大において、そもそもの組織的課題がありそうなのでチームビルディングからSREがアプローチしていくのすごい #srekaigi_hall #srekaigi

ガバクラの技術要件、どういう経緯でできあがってきたものなんだろう。耐久性数値の算定根拠とか気になる。 #srekaigi_hall #srekaigi

メルカリのSREチーム発足エントリーから今年で10年か……

『ガバメントクラウドに向けた開発と変化するSRE組織のあり方』 #srekaigi_hall #srekaigi

waroomのようなツールは、それだけで課題が解決されるゴールというより、まずはちゃんと管理して観察と分析ができるようにしようという、ある種出発点だわなー #srekaigi_b #srekaigi

MTTRの問題、 "mean" の統計上の性質によるものか #srekaigi_a #srekaigi

spot preemptionのサマリをSlackへ投稿しておくのよさそう。 #srekaigi_a #srekaigi

terraform-provider-helm かー #srekaigi_a #srekaigi

内部のAPIを元にしたin-houseなK8sのスケーラー。KEDAでもいけそう? #srekaigi_a #srekaigi

『インフラコストとセキュリティ課題解決のためのリアーキテクチャリング』 #srekaigi_a #srekaigi

SREがセキュリティに進出していくべき、は同じ気持ち。そもそもCIAのAは可用性だし。 #srekaigi_b #srekaigi

CloudTrailはGuardDutyとかでも脅威分析がされると思うけど、SIEM on Amazon OpenSearchに入れる場合との差異はどこになってくるんだろう #srekaigi_b #srekaigi

SIEMは本当にログ量が課題すぎる。種類も多いし量も増えるし。 #srekaigi_b #srekaigi

『SIEMによるセキュリティログの可視化と分析を通じた信頼性向上プロセスと実践』にきている #srekaigi_b #srekaigi

#srekaigi に来ているが、カンファレンス実況となるとやはりXになるなー。実際Blueskyでこのタグを検索してもまだポストがないっぽい。試しにクロスポストをしてみようか。

GitHub sub-issues、基本的には便利なんだけれど、tasklistでは出来たdraft(issueを作成せず、チェックリストの形でタスクだけ書き留めておく)作る機能がほしい。

GitHub、Issueに親子関係を設定できる「Sub-Issues」機能をパブリックプレビューとして公開、誰でも利用可能に - Publickey publickey1.jp/blog/25/githubissuesub-issues.html

»