システム運用アンチパターンを読んだ

読んだだけで何もしていないので何もしていない。
せっかくなので読んでいて自分たちで実践できそうと思ったことを社外秘が漏れない程度に書いていく。

ポストモーテム作成時にシステムの期待と現実の把握がしたいことを共有する

「システムの全体像の期待と現実が異なっていたとき障害が発生しやすい」というのはかなり納得できる意見。期待と現実のギャップに気づきたいことを事前に共有した上でインシデントの振り返りを行うと、メンバーから具体的イメージが出てきやそうなのでやっていきたい。

ドキュメントにはトレードオフを書く

これは昔同僚氏も話していたことで納得した。具体的な実装の中身より戦略のほうが「過去の情報」と捉えやすいし効果が高そう。また、深く詳細を書きすぎても誰も読まないという点も留意しておきたい。

機能フラグを使う

触ってるプロダクトがGraphQLサーバーとそこにクエリを投げるSPAという構成なのだけれど、新機能作るときにフロントエンドも少しづつ作りなおすので顧客に途中の状態を露出できずにわりとビックバンリリースになりがちである。
GraphQLサーバーだけ先にリリースするのはGraphQLスキーマが破壊的変更されている場合にSPAが対応できないため難しい。
上記のような困りがあったため機能フラグというのは特に運用していなかったのだけれど、システム運用アンチパターンを読んで改めて考えてみることにした。
一個浮かんだ案としては、directiveを使って以下のようにサーバ側では同名で型の違うfieldを2つ実装しておき、クライアントにはどちらかしか露出させないというもの。

directive @flagged(
  """
  Flags to check for this schema member
  """
  by: [String!]!
) on ARGUMENT_DEFINITION | ENUM | ENUM_VALUE | FIELD_DEFINITION | INPUT_FIELD_DEFINITION | INPUT_OBJECT | INTERFACE | OBJECT | SCALAR | UNION

"""
Introspection with 'ADMIN"
"""
type User {
　name: String!
  profile: String! @flagged(by: ["ADMIN"])
}

"""
Introspection with 'NOT_ADMIN"
"""
type User {
  name: String!
  profile: UserProfile! @flagged(by: ["NOT_ADMIN")
}

デプロイへの恐怖心の原因の一つであるコードのリリースと顧客への周知の帳尻を合わせを解消できそうなのでGW明け試してみたい。