先日1/25、豊洲で開催されたSRE NEXTへ行ってきました。
国内初(!)のSREのカンファレンスだったそうです。
この記事は、参加レポートの後編です。
参加レポート前編はこちら。 hibinokoto.hatenadiary.jp
後編、とても長くなってしまいました。
- D4 100万回線のIoT通信を支えるソラコムにおけるOpsDevの実践
- A5 急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略
- A6 SREがセキュアなWebシステムを構築、維持するためにやれることはなにか
- A7 サイト信頼性エンジニアリングの原則
- A8 Webサービスを1日10回デプロイするための取り組み
- A9 パネルディスカッション
- 気になった裏番組
- 感想
D4 100万回線のIoT通信を支えるソラコムにおけるOpsDevの実践
酒井憲吾 さん(株式会社ソラコム)
SRE NEXTの資料を公開しました! #srenext #srenextD
— Kengo SAKAI (@kengon) January 26, 2020
100万回線のIoT通信を支えるソラコムにおけるOpsDevの実践 / SRE NEXT 2020 in TOKYO by @SORACOM_PR #opsdev #soracom https://t.co/Z9L6r6Kyv3 @SlideShareさんから
OpsDevエンジニアの酒井さんによる、ソラコムのOpsDevのお話でした。
エンジニアは開発も運用もサポートもしているそうです。
インシデントの時に、なにか挙動がおかしいと思った時、監視の取りこぼしを防ぎたいので積極的に報告しようという方針(勘違いも推奨)が良い文化だなと思いました。
また、インシデントが起きた時、全社員へ通知されるので、セールスの方も展示会などで対応を変えられるという話がいいなと思いました。
2週間のイテレーションの終わりに、ポストモーテムで障害の原因分析をしているのも良さそうです。
サービス紹介
- 2015創業、80名
- 日本、アメリカ、シンガポール
- 繋ぐを簡単にするIoTプラットフォーム
- IoTの共通課題を解決する機能群を提供
- 事例
- 回線数が100万回線、アカウント数15,000
- 130を超える国と地域、24を超えるキャリアで繋がるIoT SIM
- 登壇者の酒井さんは、OpsDevエンジニア(ソラコム特有の言葉、SRE呼称が一般的になる前から使っている)として働いている
プラットフォームの構成要素
OpsDevの実践
開発と運用の基本原則
チーム全体で運用に責任を持つ
- 開発者
- 全員がDevOpsを実践、開発はもちろん運用もする
- OpsDevエンジニア
- 運用作業の傍ら、運用作業省力化のための開発
Horizontal Scalability
- 小さなサーバを負荷に応じて増加
Built-in Resilience
- 障害を前提とした設計
- 連携を意識せずに単独でプロセス再起動が可能な設計
- アラート発生時に監視システムからプロセス再起動で自動復旧
エンジニアはサポートもする
- サポートプライマリ制度
- サービスを運用、開発しているエンジニアが交代で問い合わせ対応をする
- 開発者が実際のお客さんと直接コミュニケーションすることで、使い勝手を向上させる手がかりを得る、足りない機能に気付ける
OpsDevエンジニアがサポートするメリット
- お客さんと直接コミュニケーションすることで、想定していないユースケースで使われていないことや、監視が足りていないポイントに気づくことができる
- お客さんとコミュニケーションできると嬉しい
- 自身の問い合わせスキルが上がり(ベンダなどへ問い合わせするタイミングがあるため)問題解決が早くなる
エンジニアは、開発も運用もサポートもする
- 専門外のタスクやるの大変
- 差込タスクが増えて集中しづらくない?
エンジニアが大切にしているカルチャー
- ソラコムのリーダーシップステートメント
- Customer Centric:お客さんの声を慶長して真のニーズを把握、サービスに反映
- Think without boudary:多角的に広い範囲で物事をみて、より大きな問題解決をする
- Dive Deep:直観に頼らずデータを元に検証して意思決定を行う
- リーダーシップステートメントに沿って行動することで評価も上がる
タスク
モニタリング
- Zabbix, Datadog ..
- 物理デバイスによる監視も
- ラズパイで監視端末を海外の拠点にも配置
- リモートで再起動できるように
- 網羅的な監視は足りないので、エミュレータによる監視(実装)して監視
- 物理とエミュレータを組み合わせて監視
インシデント対応
- システムの異常検知を、andon と呼ばれるSlack channelに書き込む
- andonが引かれたら、エンジニアは最優先で現状確認
- 不具合が確認されたらそのままトラブルシューティングへ移行
- andonは全社員に通知される
- セールスなどの人も、展示会などで把握で対応を変えられる
- なんか挙動がおかしい気がするときも、#andonに書く
- 監視の取りこぼしを防ぎたいので、そういう状況に遭遇した場合は積極的に報告しようという方針
- 勘違い推奨
andon bot
- 内製のchat botによりトラブルシューティングのサポート
- 障害報告書の雛形更新
- statuspageへの更新
お客様への速やかな情報周知
- andonチャンネルでサポートエンジニアが中心となりステータスページを更新
- 影響範囲や時刻、状況を正確に
- 必要があればセールスにも情報連携
ポストモーテム
A5 急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略
Shintaro Kaneko さん(株式会社エウレカ CTO)
本日お話した『急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略』のスライドです。
— kaneshin / eureka (@kaneshin0120) January 25, 2020
より20分では具体的な話は難しかったので、詳細はブースやカジュアルにエウレカに遊びにきて聞いてもらえればと思います!#srenext #srenextahttps://t.co/0TfMrlWFG8
エウレカCTOの金子さんによるエウレカのSREチームのミッション、指標、してきたことのお話でした。
エウレカでは、SREチームの目標や指標が明確に定義されているので、経営陣に説明しやすい、という話が印象に残りました。
サービス説明
- pairs と pairs engage
- 職能が集まったチームでプロジェクトで開発を行っている
History of Eureka and Pairs
- 8年前にリリース
- リリースしたあと、増え続ける
- データベース負荷が高い
- ユーザとユーザのコミュニケーションなのでreadもwriteも多い
- 日本と台湾の2カ国展開
- 専任のインフラエンジニア不在
- 2015年 インフラチーム発足
- PHPからGoに書き直し
- データベースのテーブル設計の大幅見直し
- スクラッチ1年3ヶ月
- 2017年からインフラチームから、SREチームに名前が変わってる
- 2017年 韓国版がリリース
SREチーム
- 不明瞭なSREチームの戦略・ビジョン
- 整備の追いついてないシステムが課題に
Why the SRE Team is at Eureka : Mission
会社の目指すビジネスの実現の阻害確率を上げる要因を全て排除することにフォーカスを当てている
What the SRE Team does at Eureka
6つの定義
SREチーム、会社として必要と思えば動きやすいが、動きにくい部分もある
- ビジネスの指標から遠いことを整備していく側面がある
- 経営をしていると短期的な目標に目が向かいがち
- 折衝がSREとしての指標定義、なぜ品質を改善していくのかという部分
- エウレカでは、目標や指標が明確化されているので経営陣に説明しやすい
What we did to achieve out Vision
- 何をしたか「土木作業」
メトリクス/ログ分析基盤 etc
- 品質の測定、改善のサイクルを回していく
- KPT
- トライは、複数挙げた中で1個を必ず達成させていくという地道な積み上げをしている
アラート/モニタリング
- ログのアラートのレベルが定義されていなかったので、再定義を行っていた
- ログレベルの再設計を行った
- アラートのレベルは、ユーザ影響でレベルを上げる
- ユーザ影響は発生しないものは無音にするなど
スケーラブル
セキュリティ
- マッチングアプリは、安心安全が担保される必要がある
- WAFを使う
- 内部の脆弱性の向上
- セキュリティ対応への時間投資のしやすいチーム単位
- アカウントマネジメントもマニュアル作業の最小化のためにIaC(Infrastructure as Code)で
その他
ダッシュボード
- 毎週問題ないか定点観測する
具体的にどういうアクションをしてきたかは、スライドをチェック
SREチームで完結してやっているわけではない
- Collaborationを大事にしている
- エウレカでは、SREが全ての信頼性責任を追わず
- SLIを共通の指標として組織的に品質改善を実施
この先
- DAU+ / MAU+
- WorldWide
- Data Reliability(分析)
A6 SREがセキュアなWebシステムを構築、維持するためにやれることはなにか
清水 勲 さん(株式会社ミクシィ)
このあと16:05からroomAでの発表資料です。 「SREがセキュアなWebシステムを構築、維持するためにやれることはなにか」 https://t.co/jwJxeHzz6U #srenext #srenextA
— Isao Shimizu @1/25 SRE NEXT (@isaoshimizu) January 25, 2020
ミクシィで、「みてね 」のSREをされている清水さんのお話。
信頼性とセキュリティはソフトウェアとシステムのライフサイクルにとって不可欠であり、セキュリティの向上にSREが貢献できる施策などについての話が良かったです。
「家族アルバム みてね」について
- こどもの写真・動画を無料・無制限に共有できるアプリ
- 国絞っていない
- 多言語対応
- AppStore/GooglePlayストアレビュー 4.7 高評価
- 「みてねプレミアム」2019年4月リリース
- Kubernetes(Amazon EKS)へ移行中
はじめに
本日持ち帰っていただきたいこと
- SREについての基本的なこと
- SREとセキュリティに関するプラクティス
- セキュリティの取り組み事例からの学び
SREについて
DevOpsとの違いは?
- class SRE implements DevOps
- DevOpsをプログラミング言語におけるインタフェースと捉えると、SREは実装である
- 開発と運用が競合するような手法ではなく、より良いソフトウェアをより早く提供するために組織の障壁を打破するように設計された親密なもの
- SREの役割はまだ初期段階
- 役割を定義しそれが何であるか正確に理解するという課題がある
- SREは技術的スキルとソフトスキルの両方を備えている必要があり効果的なコミュニケーションに熟達している・・
- チームダイナミクスのプラクティスセットが必要(チームの団結力、チーム間のコミュニケーション)
SREとセキュリティ
- SREcon でのセキュリティに関するセッションの紹介
- 年に3-4回開催されるグローバルなSREカンファレンス
- 脆弱性のバジェット
- セキュリティの問題が見つかったときに、それはいつまで大丈夫か、その期間を表すもの
- レガシーバジェット
- どれだけサポートが続くか、EOLがいつかなど
- インターネット上のトラフィックの5分の1はよくないものである
- MITではコンポーネントじゃなくてシステム全体を見ましょうなど
Google セキュリティ本
"Building Secure Reliable Systems" early release https://twitter.com/googlesre/status/1196718932247355392?s=20
- 信頼性とセキュリティはSWとシステムのライフサイクルに不可欠
- 両立したシステムを構築するのは簡単ではない
- あとで実装するのは難しい、初期から考慮できていることが望ましい
- 問題が起きてからだと深刻になりがち
- シンプルな設計、最小化された権限
- よくできたロギング
- 有事の際の指揮系統、チェックリスト、プレイブック、プロトコルは重要
- 脆弱性パッチは素早い適用が重要、しかし内容によっては問題を起こす可能性もある
セキュリティへの取り組み事例
SREチームにおけるコミュニケーションの原則
- 開発チームなど他チームとの間に壁を作らない
- 押し付け合わない、お互い理解する
- 冷静にしっかり議論する
- お互いの状況を理解し合う
- ビジネスや事業にとって優先すべきか話し合う
セキュリティの向上に貢献できる施策事例
- SREチームが開発チームに対して随時ヒアリングを実施(ここは注意してほしい!)
- Infrastructure as Code
- インフラ構築を手作業でやらない、漏れが出るから
- ツール(Terraformなど)使って、コードレビューをgithub上でやること
- 人の手で実行ではなく、CIツールで実行
- ログ収集と検索
- アップデート
- アプリケーションに依存するライブラリ
- アップデートはできるだけ自動化できると最高
- モニタリング、定期レポート
ポストモーテム
- 大事故じゃなくても作りましょう
- 障害や問題が発生した際に事象や対応を記録する
- 作った人を褒める、称賛することが大事
- 絶対に責めたり、批判しない
- ポストモーテムを振り返る(人を巻き込んで)
クラウドを扱う際に取り組むべきセキュリティ(AWS編)
AWS Well-Architected Framework
- こうした方がいいよ、というガイドラインをAWSが用意している
- https://aws.amazon.com/jp/architecture/well-architected/
- 5つの柱
- Well-Archetectedのレビューを受けられるかも?
AWSを扱う際に気を付けるべき基本的なポイント
AWSに限らずやった方がいいこと
- 責任共有モデルの理解(クラウド内のセキュリティはユーザの責任)
- クラウドに用意されているセキュリティソリューションを活用
- ネットワークを分離(インターネットアクセスは最小限に)
- 不要なポートは開けない
まとめ
- SREがセキュリティに貢献できることはたくさんある
- 信頼性とセキュリティはできるかで両立させたい
- なるべく早くやる方が被害が少なくなる
- 今は問題がない、こうなったら問題がある、というのがわかりやすい
- 手間がかかると後回しになりやすいので、できるだけ自動化する
- クラウドで用意されているセキュリティソリューションを活用する
A7 サイト信頼性エンジニアリングの原則
山口能迪 さん(Google Developer Advocate)
登壇した内容を書き下したら長い文章になってしまいました。土曜日は楽しかったです。 ▶
— 🅈🄾🅂🄷🄸 🅈🄰🄼🄰🄶🅄🄲🄷🄸 🇺🇲 (@ymotongpoo) January 27, 2020
SRE NEXT 2020で登壇してきました #srenext - YAMAGUCHI::webloghttps://t.co/FZeGyV8R7n
GoogleでのSREの実践とその背景についてのお話です。
特に、ポストモーテムの話で「人間が原因ということにしない」という原則が印象的でした。
自己紹介
- StackDriver
- Observaility
- Go担当
- 「Go言語による並行処理」翻訳
- DevOpsとSREを担当するチームにいる
SREのモットー
- ドラゴンのロゴ
- GoogleのSREチーム
- Hope is not a starategy
- 能動的に動いて、積極的にオペレーションをエンジニアリングに置き換えていく
- システムは必ず障害が起きるのでそれに対応している
単純性
信頼性の1番の敵は、複雑性(Complexity)
一貫性
- 一貫性を持つことは単純性につながる
- 特例、例外はコストが高くつく
- プラグラミング言語は統一する、標準化する
- 標準の設定管理方法、標準のOS
- 設計
- システムを作る前に設計が必要
- 慎重なレビューも必要
- 手を動かす前には、シンプルにするために設計を行って、設計のレビューをする
モニタリングとアラート
1つの方法だけでモニタリングしない、2つ以上の方法でやる
アラートに思いやり
- SLO違反になる危険性がなければページしてはダメ
- ただし、ユーザ体験が激しく損なわれるなら常に記録する
- オンコールになるものは何かを考えなければいけない
- ページ・オンコールは、人を呼び出す
- チケット・バグは、通常の業務時間で対応するもの
- 当番制を導入して今週はこの人がやる、というようにする
- 自分がやっていることを中断しなくて済む
- ログ - とっておく必要がある
- メールはダメ
- 追跡できない
- オーナーの不在
- 傍観者効果
- メールは人間が見ることを期待してやっているので、誰がそのメールを見て行動したか最終的な確認が難しい
自動化
- くりかえしはコンピュータに任せる
- puppetやAnsibleのツールを使っていこう
- さらに、GCPの場合は、gcloudコマンドで、スクリプトを渡して構築する
- 1行のコマンドで複雑なことができて抽象度を上げることができる
ステートフル vs ステートレス
- ステートフルサービスは「状態」を持つサービス
- 一意な状態をもつということは、バックアップ、モニタリング、複雑なアーキテクチャなどを持つということ
- SPOF(単一障害点)になりやすいので、なるべくステートフルにしない
情報の信頼先
- 何が正しいのか決めておく、というのはとても重要
- モニタリングするとき、どこを正とするか、を定めておくことは大事
SL?
- SLOを正しく決めると何ができるか?
- エラーバジェットを決めることができる
- 可用性99.9%は、残りの0.1%が全ての行動の「予算」にある
- 余裕が生まれる
- メンテナンス/デプロイ
- 障害耐性テスト
エラーバジェット
- 0.5%であれば1ヶ月間に3.6時間ダウンタイムが許容される
- この余裕の時間があることにより、新しいことをどんどんやっていける
- 計画メンテナンスをしなくても、3.6時間あれば止まってもいいので、できることが増える
- SLOとそれに対応するエラーバジェットを正しく決めることで、組織的に運用がしやすくなる
- 厳しいSLOは変更速度が下がる
- SLOがないと、早く変更しすぎたりインフラがサポートできなくなったりする
テストとロールバック
- システムはいずれ落ちる
- 次の対策で緩和すべき
- 累進的なロールアウト
- 変更後の検証
- 準備済みロールバック
- ロールバックをするときに大事なことは、ある変更を加えるときに、変更リクエストのドキュメントに、ロールバックの方法も検討する必要がある
- ロールバックしやすくしておくことが大事
障害耐性
- あるサービスをプッシュしたら空の設定ファイルを作ってしまい、それが原因でサービスの再起動後にサービスが落ちてしまった障害
- 動かしながら設定をロードするような仕組みにする
- 設定が間違っていたら、前の状態を維持しながら動かし続ける
- 間違っている自体はアラートする
- どういう項目が変わっていたらまずいかを検討する
- 大きい変更がある場合は自動的に取り込まないようにする、などを組み込んでおく
- そういうことをする場合には、先にテストしておく必要がある
- 本番で動く前に行う
- 大きな変更の後に行う
- 新人がいるときにいい練習になるのでやってみる
- しばらくテストが行われていなかったら行う
- できるときはいつでもやる!学びがある
ポストモーテム
- SREにとって一番大事
- ポストモーテムは非難がなく人間ではなくプロセスと技術に注目するもの
- 人間が原因ということにしない
- 人間は必ずミスをするので、それは人間のせいではない
- ヒューマンエラーが起きたとき、なぜそれが起きたのか?を考えて、システム側で防げたのではないかと考える
- こうした障害の再発をポジティブに防ぐにはどうしたらいいか
- 同様の障害を正確に検出するまでの時間を減らすにはどうしたらいいか
Google - Site Reliability Engineering
- もっと詳しくはこのページを見てくださいとのこと
- https://landing.google.com/sre/
A8 Webサービスを1日10回デプロイするための取り組み
藤原 俊一郎(面白法人カヤック)
これから話す基調講演の資料です https://t.co/vMBFIKwqMa #srenext
— fujiwara (@fujiwara) January 25, 2020
Lobiというサービスを、1日10回デプロイできるようにするために、デプロイに関わる構成要素について何をしてきたかというお話でした。
地道に一つずつツールを作ったり改善されてきたお話でした。コンテナになっても考え方は同じというのが印象的でした。
サービス
- "Lobi"というゲームユーザ向けのコミュニティサービス
- マイクロサービス的なものGo(かつてNode, 最近全廃)
1日10回デプロイしたい
- 休前日にデプロイはしない
- 7時間で10回デプロイするためには
- 1回のデプロイを高速化する
- 誰でもデプロイできるように(専任の担当者を作らない)
- いつ何がデプロイされたか管理できるようにする
デプロイの要素
CI
- 巨大なモノリス
- モックせずにMySQLやRedisをそのまま使っている
- Jenkins master+slave
- 強いEC2インスタンスでやっていた
- 64コアで力任せに10分
- CIが遅いことによるストレス
- 緊急対応時にもどかしかったり
- CircleCIがいいらしいと聞いたので導入
- 8コアのコンテナを並列で起動できる、従量課金
- GitHubでPRを作ってdescription書いているうちに、CIが終わっている!!!
- Tips
- テストのイメージ配置場所は、CircleCIはus-east-1にある(現時点)
- テスト用イメージもus-east-1におくと良い(東京にあるといろいろ高い)
ビルド/配布
- ファイル配布高速化の歴史
- ツールを作った Stretcher
- 2014年
- S3にファイルをあげそれを各サーバが引っ張ってきて自分で展開する
- オートスケールしても、自分でpullしてくるので配布される
- 1分になった、そのまま待てる
- S3の強さに依存した仕組み、S3が耐えてくれるかぎりスケールする
エラー検知(ロールバックするために)
- デプロイ後、エラーがないことを確認しないと完了できない
- できれば1分なら待てる
- Noricraというツール
- ログ検知を適切なwindowで実行する
- エラーが大量発生しても1分に1回だけ通知する(通知を爆発させない)
ロールバック
- pull型デプロイ
- 今回のデプロイ直前までデプロイされていた成果物はS3にある
- 素朴なロールバックは、デプロイをもう一度すれば良い
誰でもデプロイできる仕組み
- 誰でもコード書いた人がデプロイできるようにしている
- RundeckをいうWebUIのツールを使った
- 単にシェルをたたくためのラッパーとして使っている(依存しないように、ツールを変更することができるように)
- デプロイ履歴を管理する
- いつ何がデプロイされたのか記録したい
- ghchでデプロイに含まれるPRを取得して記録
- https://github.com/Songmu/ghch
- Google Calendarでデプロイした記録が見れるようにしている
- Slack botによるデプロイの管理
- 「休前日前だけどデプロイしていいの?」など注意喚起
コンテナ移行後のデプロイ
- 配布/ロールバックはStrecherからECSに
- ECRにリポジトリからイメージを引っ張ってくることになる
- ecspressoというデプロイツールを作った
- 他のツールやコンソールで作ったECSタスク/サービスも簡単にコード管理に落とし込める
- エラー検知は、Firehose+S3+Lambda
まとめ
- 構成要素を全て高速化することでデプロイの高速化をする
- 誰でもデプロイできる仕組みは開発体験に重要
- EC2からECR(コンテナ)になっても考え方は同じ
- よりスケールしやすい構成にしてゆく
A9 パネルディスカッション
なんだかものすごいメンバーのパネルディスカッションでした。
SREワークショップの本の出版準備が進んでいるようです!
- 関根 達夫さん
- 玉川 竜司さん
- 樽石 将人さん
- 田中 慎司さん
- 2006年株式会社はてなに入社、2010年よりCTO。2016年9月、メルカリに入社。現在は日本でメルカリのMicroservices化を旗振りされている。
スキルセットは?
- rettyはSREチームはない
- SREのスキルセットがなにかは組織の課題によるところがあるので一概には言えない
- SLIやSLOを拠り所に組織運営するなら、データを集めて統計処理して数学的な話になるので、webのいろんな知識、数学の統計知識など
- チームとしていろんなバックグラウンド、スキルセットがあることが理想
SREの取り組みを始めるときこうしておけばよかったなど思うところあれば
- rettyでSRE的な取り組みは、SEOやっていきユーザが増えてきた時負荷に耐えられないとき、やりはじめたのが最初
- フロントキャッシュを入れて負荷下げようとした
- 一晩で入れたフロントキャッシュが今も残っている
- ユーザがまだいないときになくしておきたかったがトラフィックが増えて外しづらくなっている
- トラブルがあったときに全社を巻き込んでおけばよかった
SREの役割について
- つまみ食いでいいのではないか
- 取り入れられることを地道に取り入れていけば良いのでは
SREの会社に対する指標はどうあるべきか
- googleでは、プロダクトチームから雇われてるような存在
- ソフトウェアエンジニアが、専門のSREがやったほうがうまくいくはずという形で雇ってもらってる
- ソフトウェアエンジニアのさらに専門職としてすばやく専門的にできることが期待されていることと考えている
- 基本的には、信頼性とのプロダクティビティーバランスをいかに取るかを専門的にバランスを取る
- サービスの種類や会社の状態によって変わるので、そのバランスを高めることが期待されていることでは
SREチームが存在すべきか、プロダクトチームの中にSRE的な動きをするエンジニアがいるべきか?
- プロダクトチームの中にいた方が良いのでは、rettyはインフラエンジニアが多い
- googleにいたときSREやってたときは、ユーザに見える部分のフロントのSREをやっていた
- いろんなところにSREとして入っていく
- SREのなかで、バックエンドだけでなくもっと上もある
採用、評価、育成
- SREに特別なことはしていない、ソフトウェアエンジニアと同じところでやっている
- google関根さん、SREもプログラム書けることが大前提、専門として雇うことはない
- 経歴見ると、バックエンド触った人をSREとして採用してるくらいしかない
評価
- メルカリでは、日本では早い段階でSREをつくった
- OKRも取り入れてる
- それに向かってどれくらい貢献したかで評価
- SLI、SLOで、チームで評価してもらう
SREの重要性を理解させるには
- 信頼性大事という人は、いままで失敗してる人が多い
- トラブルに自分ごととして触れる
SRE本どういう人に読んでもらうといいか
- 玉川さん(翻訳者):今まで運用やっていた方が、運用単調と思ってた人が、SRE本読んで、それをもっとたのしくプロアクティブにできるようになってくれるとよいのでは
属人化させない工夫
- 休みを取りたいのでSREだけでなく属人化させない
- 2人ペアで仕事させるようにしていた
- コードレビューお互いにしていた、どちらが休んでも大丈夫にしていた
今後のSRE
- 短期的には、クラウドが伸びていて、一方オンプレもまだある
- 現状の技術基盤を賢く活用してサービスをうまく運用していくのが大事
- 長期的には、不要にしようとがんばるだろうけど、どこまでいくかは技術の進歩による
- 会社や出してるサービスに大きく依存する
- SRE残るだろうが、SREというものがいらなくなる会社は増えるかも
- クラウドがのびていて、heroku、firebaseとかがカバーできるところがふえてくる
- 専門職までは要らないという会社は増えていくかも
- firebaseを作る人はいるので、それは必要
- クラウドや大きなインフラまわす人になる
- クラウドスペシャリストみたいな人は必要
- 立場的にSREがそれになりそう
- 専門職があるかというと、なくなる方向
- SREがいらない、なんでもできるようなものをgoogleやamazonさんが出してくれるとうれしい
- SREの原理は残っていくだろう
- 専門職として残っていくかは不透明
SREやっていてこれはよかったなと思ったこと
- 関根さん:google トータルで書いた行数がマイナス10万行くらい
- 目に見えるものができたのはよかったなと思う
- googleは地球全体なので、トラフィックが出る、とか、人の息吹とか人が活動していることが分かる、作ったものが使われていることがわかる
- デプロイしてトラフィックさばくことで人の役に立ってることが息吹を感じられる
コメント
- 玉川さん:SREのワークブックの出版準備進んでいる 夏くらいまでには出るかも?
気になった裏番組
同じ時間帯に、気になるセッションがたくさんあって、どの枠もすごく迷いました・・・。
気になったいくつかのセッションのスライドを貼ります。読みたい・・。
先ほど SRE NEXT 2020 で発表した資料を公開しました! ご参加いただいた皆さま、ありがとうございました 🙏 #srenext #srenextA / freee のエンジニアは障害から何を学び、どう改善しているのか? https://t.co/DUvpCC411L
— Manabu Sakai (@manabusakai) January 25, 2020
13:50 から Room A で発表する資料ですhttps://t.co/i3D2PeXxb2#srenext #srenextA
— tkuchiki (@tkuchiki) January 25, 2020
スライド公開しました! #srenext #srenextC
— gomesuit (@gomesuit) January 25, 2020
delyにおける安定性とアジリティ両立に向けたアプローチ / SRE NEXT 2020 https://t.co/VkANu9va1T
死霊です #srenext / SRE Practices in Mercari Microservices https://t.co/1Q90ut0fS6
— Taichi Nakashima (@deeeet) January 25, 2020
本日の資料です | [C4]SRE Review https://t.co/0JIyZwFNPu https://t.co/pZqp9hZhfL #srenext #srenextC
— 🤔 (@chaspy_) January 25, 2020
発表資料公開しました!
— k_mrgk (@k_mrgk) January 25, 2020
Blue-Green デプロイメントを採用したデプロイの仕組みを実装して共通基盤として導入した話 / SRE NEXT 2020 https://t.co/xLtNlFqwlk#srenext
SRE NEXTでの発表資料です(遅くなりました) #srenext #srenextC https://t.co/t0X9okYl7F
— licht110 (@licht_110) January 25, 2020
感想
SREではないけれど・・・と引け目を感じながら参加したこのイベント、とても良かったです。
何が良かったかというと、それぞれの現場でやっている実践の内容の発表が多く、実践で得たことや工夫していることなどに一気に触れられるめったにない機会だったというのが大きいです。
初のカンファレンスということで、きっと開催には大変なことがいろいろあったと思うのですが、とても充実したカンファレンスでした。
ありがとうございました!!