![](https://s.togetter.com/static/web/img/placeholder.gif)
SRE NEXT 2020 まとめ(後半戦)
![](https://s.togetter.com/static/web/img/placeholder.gif)
SREて名乗っていいのか不安めちゃわかるううううわかるううう。 「SRE本に書いてあること全部できてなくても、ちょっとずつやっていけばいいんだよ」というぐう聖コメント #srenext
2020-01-25 18:52:08![](https://s.togetter.com/static/web/img/placeholder.gif)
SREとインフラという言葉の使い分けは多少conventionっぽいところもありそう #srenext
2020-01-25 18:52:18![](https://s.togetter.com/static/web/img/placeholder.gif)
Q. SREの内容はどこまでやればSREしてると言えますか? A. つまみぐいでいいんじゃないか。入れられそうなものを地道にやってこう #srenext
2020-01-25 18:52:51![](https://s.togetter.com/static/web/img/placeholder.gif)
Googleさん内だとSREチームがプロジェクトチームに雇われている様子 大きな組織だとSREチームを専用チームとして分けるリソースもあり良さそう (コミュニケーションコストは発生しそうだけど) #srenext
2020-01-25 18:53:53![](https://s.togetter.com/static/web/img/placeholder.gif)
SRE bookの原理原則をどこまで適用すればSREと言えるのか? -> つまみぐいでよい #srenext
2020-01-25 18:53:56![](https://s.togetter.com/static/web/img/placeholder.gif)
ソフトウェアエンジニアの中での専門職としての SRE。似たような感じだとテストエンジニアとして存在するSET みたいなものと同等ってことかしら #srenext
2020-01-25 18:54:30![](https://s.togetter.com/static/web/img/placeholder.gif)
つまみ食いでいいんじゃない?は個人的にはすごく「ですよねえ」な感じがしますし自分もSREという肩書ではない。自組織にあった有用なプラクティスを取り入れたらいいんでないかと思う。 #srenext
2020-01-25 18:54:43![](https://s.togetter.com/static/web/img/placeholder.gif)
Googleでさえ SRE の成果を Measurable にするのは難しいと思っている、ということだろうか? #srenext
2020-01-25 18:54:52![](https://s.togetter.com/static/web/img/placeholder.gif)
初めて自分にとってピンポイントなカンファレンスなんだけど、自分の職種のカンファレンスがこんなに面白いものだって知った。 ルッビカイギとかの参加者の気持ちがわかった #srenext
2020-01-25 18:55:05![](https://s.togetter.com/static/web/img/placeholder.gif)
SREの貢献内容「信頼性/プロダクティビティのトレードオフのバランスを高度なレベルで保つ。会社のフェーズに応じた判断を行う。」 おっも… #srenext
2020-01-25 18:55:25![](https://s.togetter.com/static/web/img/placeholder.gif)
SREは、信頼性とプロダクティビティのバランスをとるプラクティスの集合だと思っており、そんな動きをして欲しいのが経営者側からの期待ではないか ためになる #srenext
2020-01-25 18:55:36![](https://s.togetter.com/static/web/img/placeholder.gif)
SREというチームが存在すべきなのか、プロダクトチームの中にSRE的な動きをするエンジニアがいるべきなのか #srenext
2020-01-25 18:55:36![](https://s.togetter.com/static/web/img/placeholder.gif)
Q. SREの組織的な期待値、成果って何? A. SREに期待されるのは生産性と信頼性のバランスをとること。サービスの特性、組織のフェーズによって割合も変化していく。その辺りを継続して提供していくこと。 #srenext
2020-01-25 18:55:47![](https://s.togetter.com/static/web/img/placeholder.gif)
SREチームが存在するべきか、プロダクトチームにSREを用意するべきか→ 「プロダクトチームにいる方がいいと思う、1プロダクトに複数開発チームがある場合は開発チームにアサインするのがいいかも」 #srenext
2020-01-25 18:57:33![](https://s.togetter.com/static/web/img/placeholder.gif)
Q. SREチームがあるべきなのかチームにそれを担当するエンジニアがいるべきなのか A. SREはインフラオンリーの内容ではなくサービス提供目線で考えるといい #srenext
2020-01-25 18:58:14![](https://s.togetter.com/static/web/img/placeholder.gif)
SREの手法に精通している、SREのベストプラクティスを意識してアプリケーションを作っているエンジニアはSREエンジニアの本来の姿なのかな、とも思う 専用チームとしてプロダクトから離し過ぎると失うことも大きそう、特にドメインdependentのもの #srenext
2020-01-25 18:58:20![](https://s.togetter.com/static/web/img/placeholder.gif)
SRE、ソフトウェアエンジニアとして採用してアサインするパターンが多いんか。 インフラ要素もわかってないとしんどいとおもうけど、もしかして最近のソフトウェアエンジニアはインフラ要素もわかっているというのか… #srenext
2020-01-25 18:58:58![](https://s.togetter.com/static/web/img/placeholder.gif)
確かにSRE=インフラだと、フロントエンドやアプリのチューニングなりReliabilityをあげる人がいないことになってしまうので、色んな領域にSREがいて良いのかもしれないな #srenext
2020-01-25 18:59:03