日々のこと

まいにちの暮らしをつれづれ書きます

SRE NEXTへ行ってきました(後編)

先日1/25、豊洲で開催されたSRE NEXTへ行ってきました。
国内初(!)のSREのカンファレンスだったそうです。
この記事は、参加レポートの後編です。

sre-next.dev

発表資料まとめ
タイムテーブル

参加レポート前編はこちら。 hibinokoto.hatenadiary.jp

後編、とても長くなってしまいました。

D4 100万回線のIoT通信を支えるソラコムにおけるOpsDevの実践

酒井憲吾 さん(株式会社ソラコム)

OpsDevエンジニアの酒井さんによる、ソラコムのOpsDevのお話でした。
エンジニアは開発も運用もサポートもしているそうです。
インシデントの時に、なにか挙動がおかしいと思った時、監視の取りこぼしを防ぎたいので積極的に報告しようという方針(勘違いも推奨)が良い文化だなと思いました。
また、インシデントが起きた時、全社員へ通知されるので、セールスの方も展示会などで対応を変えられるという話がいいなと思いました。
2週間のイテレーションの終わりに、ポストモーテムで障害の原因分析をしているのも良さそうです。

サービス紹介

  • 2015創業、80名
  • 日本、アメリカ、シンガポール
  • 繋ぐを簡単にするIoTプラットフォーム
    • IoTの共通課題を解決する機能群を提供
  • 事例
  • 回線数が100万回線、アカウント数15,000
  • 130を超える国と地域、24を超えるキャリアで繋がるIoT SIM
  • 登壇者の酒井さんは、OpsDevエンジニア(ソラコム特有の言葉、SRE呼称が一般的になる前から使っている)として働いている

プラットフォームの構成要素

  • Dipper
  • Polaris
  • Hubble(監視)

  • ソラコムのプラットフォームはAWS

  • マイクロサービスで構築

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

お客様への速やかな情報周知

  • andonチャンネルでサポートエンジニアが中心となりステータスページを更新
    • 影響範囲や時刻、状況を正確に
  • 必要があればセールスにも情報連携

ポストモーテム

A5 急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

Shintaro Kaneko さん(株式会社エウレカ CTO)

エウレカCTOの金子さんによるエウレカのSREチームのミッション、指標、してきたことのお話でした。
エウレカでは、SREチームの目標や指標が明確に定義されているので、経営陣に説明しやすい、という話が印象に残りました。

サービス説明

  • pairs と pairs engage
  • 職能が集まったチームでプロジェクトで開発を行っている

History of Eureka and Pairs

  • 8年前にリリース
    • リリースしたあと、増え続ける
  • データベース負荷が高い
    • ユーザとユーザのコミュニケーションなのでreadもwriteも多い
  • 日本と台湾の2カ国展開
  • 専任のインフラエンジニア不在
  • 2015年 インフラチーム発足
  • PHPからGoに書き直し
  • データベースのテーブル設計の大幅見直し
  • 2017年からインフラチームから、SREチームに名前が変わってる
  • 2017年 韓国版がリリース

SREチーム

  • 不明瞭なSREチームの戦略・ビジョン
  • 整備の追いついてないシステムが課題に

Why the SRE Team is at Eureka : Mission

会社の目指すビジネスの実現の阻害確率を上げる要因を全て排除することにフォーカスを当てている

What the SRE Team does at Eureka

  • 6つの定義

    • 99.95%の可用性
    • クリティカルなセキュリティリスク撲滅
    • 運用自動化および自己修復可能なシステム基盤構築による少数精鋭の運用体制
    • キャパシティプラニングに基づくコストコトロールにより利益率の向上へ寄与
    • リリースエコシステムの改善と安定化
    • 事業価値最大化のための施策サポート
  • SREチーム、会社として必要と思えば動きやすいが、動きにくい部分もある

    • ビジネスの指標から遠いことを整備していく側面がある
    • 経営をしていると短期的な目標に目が向かいがち
      • 折衝がSREとしての指標定義、なぜ品質を改善していくのかという部分
    • エウレカでは、目標や指標が明確化されているので経営陣に説明しやすい

What we did to achieve out Vision

  • 何をしたか「土木作業」

メトリクス/ログ分析基盤 etc

  • 品質の測定、改善のサイクルを回していく
  • KPT
    • トライは、複数挙げた中で1個を必ず達成させていくという地道な積み上げをしている

アラート/モニタリング

  • ログのアラートのレベルが定義されていなかったので、再定義を行っていた
  • ログレベルの再設計を行った
    • アラートのレベルは、ユーザ影響でレベルを上げる
    • ユーザ影響は発生しないものは無音にするなど

スケーラブル

  • Packer & Terraformの構成からAWS Fargateを導入
  • Webサーバをコンテナ化
  • リリースノート、デプロイ、ロールバックの承認をどうとるのか

セキュリティ

  • マッチングアプリは、安心安全が担保される必要がある
    • WAFを使う
    • 内部の脆弱性の向上
    • セキュリティ対応への時間投資のしやすいチーム単位
    • アカウントマネジメントもマニュアル作業の最小化のためにIaC(Infrastructure as Code)で

その他

この先

  • DAU+ / MAU+
  • WorldWide
  • Data Reliability(分析)

A6 SREがセキュアなWebシステムを構築、維持するためにやれることはなにか

清水 勲 さん(株式会社ミクシィ

ミクシィで、「みてね 」のSREをされている清水さんのお話。
信頼性とセキュリティはソフトウェアとシステムのライフサイクルにとって不可欠であり、セキュリティの向上にSREが貢献できる施策などについての話が良かったです。

「家族アルバム みてね」について

  • こどもの写真・動画を無料・無制限に共有できるアプリ
  • 国絞っていない
    • 多言語対応
  • AppStore/GooglePlayストアレビュー 4.7 高評価
  • 「みてねプレミアム」2019年4月リリース
  • KubernetesAmazon EKS)へ移行中

はじめに

本日持ち帰っていただきたいこと

  • SREについての基本的なこと
  • SREとセキュリティに関するプラクティス
  • セキュリティの取り組み事例からの学び

SREについて

DevOpsとの違いは?

  • class SRE implements DevOps
  • 開発と運用が競合するような手法ではなく、より良いソフトウェアをより早く提供するために組織の障壁を打破するように設計された親密なもの
  • 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チームが開発チームに対して随時ヒアリングを実施(ここは注意してほしい!)
    • どんなライブラリを使ってる?
    • トークン取扱どうする?
    • パスワードの取扱どうする?
    • TLSのバージョン
    • クライアントに保持している情報
    • ログに個人情報が載っている(マスクする)
    • アプリ内に脆弱性があったときセキュリテイアップデートを強制できる機能
  • Infrastructure as Code
    • インフラ構築を手作業でやらない、漏れが出るから
    • ツール(Terraformなど)使って、コードレビューをgithub上でやること
    • 人の手で実行ではなく、CIツールで実行
  • ログ収集と検索
  • アップデート
    • アプリケーションに依存するライブラリ
    • アップデートはできるだけ自動化できると最高
  • モニタリング、定期レポート

ポストモーテム

  • 大事故じゃなくても作りましょう
  • 障害や問題が発生した際に事象や対応を記録する
    • 作った人を褒める、称賛することが大事
    • 絶対に責めたり、批判しない
    • ポストモーテムを振り返る(人を巻き込んで)

クラウドを扱う際に取り組むべきセキュリティ(AWS編)

  • クラウドセキュリティはAWSの最優先事項
  • 責任共有モデル
    • 使ってるクラウドがどういうコンセプトを持っているかを確認する

AWS Well-Architected Framework

AWSを扱う際に気を付けるべき基本的なポイント

  • セキュリティサービス
    • TCP 22番ポートでなくSecurity Managerを使ったSSHアクセス
  • IAM
    • 退職者/異動者を削除
    • AWSアカウントを環境ごとに分ける
  • 出所不明のパブリックAMIを使わない
  • S3バケットは直接インターネットに公開しない

AWSに限らずやった方がいいこと

  • 責任共有モデルの理解(クラウド内のセキュリティはユーザの責任)
  • クラウドに用意されているセキュリティソリューションを活用
  • ネットワークを分離(インターネットアクセスは最小限に)
  • 不要なポートは開けない

まとめ

  • SREがセキュリティに貢献できることはたくさんある
  • 信頼性とセキュリティはできるかで両立させたい
    • なるべく早くやる方が被害が少なくなる
    • 今は問題がない、こうなったら問題がある、というのがわかりやすい
  • 手間がかかると後回しになりやすいので、できるだけ自動化する
  • クラウドで用意されているセキュリティソリューションを活用する

A7 サイト信頼性エンジニアリングの原則

山口能迪 さん(Google Developer Advocate)

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時間ダウンタイムが許容される
    • カナリアリリースしている場合、ダウンタイムの収まるかぎり、低リスクの変更であれば、検証、カナリアの期間を短くしたり、直接カナリアを飛ばしてstableにプッシュするという選択も取れるかも
  • この余裕の時間があることにより、新しいことをどんどんやっていける
    • 計画メンテナンスをしなくても、3.6時間あれば止まってもいいので、できることが増える
  • SLOとそれに対応するエラーバジェットを正しく決めることで、組織的に運用がしやすくなる
  • 厳しいSLOは変更速度が下がる
    • SLOがないと、早く変更しすぎたりインフラがサポートできなくなったりする

テストとロールバック

  • システムはいずれ落ちる
  • 次の対策で緩和すべき
  • ロールバックをするときに大事なことは、ある変更を加えるときに、変更リクエストのドキュメントに、ロールバックの方法も検討する必要がある

障害耐性

  • あるサービスをプッシュしたら空の設定ファイルを作ってしまい、それが原因でサービスの再起動後にサービスが落ちてしまった障害
    • 動かしながら設定をロードするような仕組みにする
    • 設定が間違っていたら、前の状態を維持しながら動かし続ける
    • 間違っている自体はアラートする
  • どういう項目が変わっていたらまずいかを検討する
    • 大きい変更がある場合は自動的に取り込まないようにする、などを組み込んでおく
  • そういうことをする場合には、先にテストしておく必要がある
    • 本番で動く前に行う
    • 大きな変更の後に行う
    • 新人がいるときにいい練習になるのでやってみる
    • しばらくテストが行われていなかったら行う
    • できるときはいつでもやる!学びがある

ポストモーテム

  • SREにとって一番大事
  • ポストモーテムは非難がなく人間ではなくプロセスと技術に注目するもの
  • 人間が原因ということにしない
    • 人間は必ずミスをするので、それは人間のせいではない
    • ヒューマンエラーが起きたとき、なぜそれが起きたのか?を考えて、システム側で防げたのではないかと考える
  • こうした障害の再発をポジティブに防ぐにはどうしたらいいか
  • 同様の障害を正確に検出するまでの時間を減らすにはどうしたらいいか

Google - Site Reliability Engineering

A8 Webサービスを1日10回デプロイするための取り組み

藤原 俊一郎(面白法人カヤック

Lobiというサービスを、1日10回デプロイできるようにするために、デプロイに関わる構成要素について何をしてきたかというお話でした。
地道に一つずつツールを作ったり改善されてきたお話でした。コンテナになっても考え方は同じというのが印象的でした。

サービス

  • "Lobi"というゲームユーザ向けのコミュニティサービス
  • マイクロサービス的なものGo(かつてNode, 最近全廃)

1日10回デプロイしたい

  • 休前日にデプロイはしない
  • 7時間で10回デプロイするためには
    • 1回のデプロイを高速化する
    • 誰でもデプロイできるように(専任の担当者を作らない)
    • いつ何がデプロイされたか管理できるようにする

デプロイの要素

CI

  • 巨大なモノリス
  • モックせずにMySQLやRedisをそのまま使っている
  • Jenkins master+slave
  • CIが遅いことによるストレス
    • 緊急対応時にもどかしかったり
  • CircleCIがいいらしいと聞いたので導入
    • 8コアのコンテナを並列で起動できる、従量課金
    • GitHubでPRを作ってdescription書いているうちに、CIが終わっている!!!
  • Tips
    • テストのイメージ配置場所は、CircleCIはus-east-1にある(現時点)
    • テスト用イメージもus-east-1におくと良い(東京にあるといろいろ高い)

ビルド/配布

  • ファイル配布高速化の歴史
    • 昔は各サーバにgit pullしていた
    • ビルドしたものがgitリポジトリにないといけなかった
    • あるサーバでビルドしたものをrsyncでばらまいていた 10並列でrsyncして3-4分(暇) 2013年
    • あるところからファイルを配るのはオートスケールしにくい
  • ツールを作った Stretcher
    • 2014年
    • S3にファイルをあげそれを各サーバが引っ張ってきて自分で展開する
    • オートスケールしても、自分でpullしてくるので配布される
    • 1分になった、そのまま待てる
    • S3の強さに依存した仕組み、S3が耐えてくれるかぎりスケールする

エラー検知(ロールバックするために)

  • デプロイ後、エラーがないことを確認しないと完了できない
  • できれば1分なら待てる
  • Noricraというツール
    • ログ検知を適切なwindowで実行する
    • エラーが大量発生しても1分に1回だけ通知する(通知を爆発させない)

ロールバック

  • pull型デプロイ
  • 今回のデプロイ直前までデプロイされていた成果物はS3にある
  • 素朴なロールバックは、デプロイをもう一度すれば良い

誰でもデプロイできる仕組み

  • 誰でもコード書いた人がデプロイできるようにしている
  • RundeckをいうWebUIのツールを使った
    • 単にシェルをたたくためのラッパーとして使っている(依存しないように、ツールを変更することができるように)
  • デプロイ履歴を管理する
    • いつ何がデプロイされたのか記録したい
  • ghchでデプロイに含まれるPRを取得して記録
  • Slack botによるデプロイの管理
    • 「休前日前だけどデプロイしていいの?」など注意喚起

コンテナ移行後のデプロイ

  • 配布/ロールバックはStrecherからECSに
  • ECRにリポジトリからイメージを引っ張ってくることになる
  • ecspressoというデプロイツールを作った
    • AWS SDK Goの構造体を使うことで新機能の取り込みも簡単にできるように
  • 他のツールやコンソールで作ったECSタスク/サービスも簡単にコード管理に落とし込める
  • エラー検知は、Firehose+S3+Lambda

まとめ

  • 構成要素を全て高速化することでデプロイの高速化をする
  • 誰でもデプロイできる仕組みは開発体験に重要
  • EC2からECR(コンテナ)になっても考え方は同じ
    • よりスケールしやすい構成にしてゆく

A9 パネルディスカッション

なんだかものすごいメンバーのパネルディスカッションでした。
SREワークショップの本の出版準備が進んでいるようです!

スキルセットは?

  • 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がいらない、なんでもできるようなものをgoogleamazonさんが出してくれるとうれしい
  • SREの原理は残っていくだろう
  • 専門職として残っていくかは不透明

SREやっていてこれはよかったなと思ったこと

  • 関根さん:google トータルで書いた行数がマイナス10万行くらい
    • 目に見えるものができたのはよかったなと思う
  • googleは地球全体なので、トラフィックが出る、とか、人の息吹とか人が活動していることが分かる、作ったものが使われていることがわかる
    • デプロイしてトラフィックさばくことで人の役に立ってることが息吹を感じられる

コメント

  • 玉川さん:SREのワークブックの出版準備進んでいる 夏くらいまでには出るかも?

気になった裏番組

同じ時間帯に、気になるセッションがたくさんあって、どの枠もすごく迷いました・・・。
気になったいくつかのセッションのスライドを貼ります。読みたい・・。

感想

SREではないけれど・・・と引け目を感じながら参加したこのイベント、とても良かったです。
何が良かったかというと、それぞれの現場でやっている実践の内容の発表が多く、実践で得たことや工夫していることなどに一気に触れられるめったにない機会だったというのが大きいです。
初のカンファレンスということで、きっと開催には大変なことがいろいろあったと思うのですが、とても充実したカンファレンスでした。
ありがとうございました!!