＼回答があります！／

• 

  北野勝久

  エンジニア

  2年前
  こんにちは、はじめまして。
  まさに私自身が「SRE（GraphQLの知識はない人）」に該当する（少なくともGraphQLで本番環境レベルのアプリケーション開発・運用に携わったことはありません）ので、私だったらどうコミュニケーションするだろうかを考えてみました。
  
  アプリケーション・インフラに関わる基本的なモニタリング（Four Golden Signals: https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals に準ずるもの）が整っている前提で考えてみると、いっしょに本番環境へのリリース・監視まわりを整備するために知りたい情報としては、以下のような部分でしょうか。
  
  - 現状と比較して、具体的にパフォーマンスの懸念があるのはどういう場合があるか
  - 本番環境で起こりうるリクエストを模倣した負荷をつかっての、負荷試験の結果があれば嬉しい
  
  リクエストボディの肥大化やHTTPキャッシュにのらない処理が具体的にどう既存システムに影響を及ぼすかを事前検証したい気持ちがあるので、その不安を取り除けるよう協力できると嬉しいなと思いました。
  あと監視するだけでなく、事前に前段でブロックすべきものをブロックできるよう手（たとえば、Query depthのようなものでクエリのコスト制限をかけるイメージ）も打てていると安心してリリースを迎えられそうですね。
  view数 10
  • 3
  • 2
  • 2

• 

  石川寛之

  プロジェクトマネジメント

  2年前
  初めまして。自分が、去年 業務委託で関わっていたところ（オンライン展覧会／NFT事業）では、AWS の Cloudwatchにアラートを飛ばす➡Slackに通知する。で、backendエンジニアが監視していました。そこでは、SRE担当はいませんでしたが、某〇BIでセキュリティ系のチームを立ち上げる際は、SREのリソースが必須だったので、監視アラートのレギュレーション、仕組み化を提案した後、人選を揃えようとした経緯もありました。なので、整備を整えてから巻き込むというのは、一番分かり易いのではないでしょうか。もしくは、その逆（カオスから生地化）を楽しみたい人なら そこから誘うのもいいのではと思います。
  view数 11
  • 1
  • 2