😡

イケイケなSREチームの人たちをイライラなSREチームの人たちにする方法（β版）

2023/12/18に公開

poem

SRE

jtc

idea

SREだか何だか知らねぇけどよ～～

最近、なんか鼻につくワードありませんか～？
そう！

あんだそりゃぁ？
どういう意味なんだオラァァン
あぁ？サイトリララビティエンジニアリングだぁぁ？
かっこつけやがってよぉ
モニタリングだかオブザビリティだかなんだか知らねえけど流行に乗って調子こいてねぇかぁ？？
なんかシャレオツなイベントで偉そうに登壇してドヤってるけどよぉ！結局お目当ては打ち上げで酒呑むことだろ～～～？
お前らタダのインフラエンジニアだろぉ？名前変えてイキってんじゃぁねぇぞオラァァン

と社内でSREを専門とするチームが立ち上がってヤキモキしている方が中にはいるかもしれません。
大丈夫です！任せてください！そういうチームに所属するイケイケな人たちをイライラさせて退職届を出させる術をお教えします！
これからご紹介することを全てこなせばSREチームを崩壊させることが出来ます！
それでは始めてイキまっしょう！！

超概算

まず最初に我が社もDXするのだ～～～！ってなるとスマホアプリとかみたいなDXっぽい開発始まるじゃないですか？で、大体「SREチーム」みたいなところがなんやかんやオンプレのインフラエンジニアがやってきたことを賄うわけですよ。DXっていうくらいだから大概AWSやらAzureやらGCP（順不同）でプラットフォームを構築していくことになると思うんですけど当然そのプラットフォームにどの位のお金がかかるかを見積もりして予算立てしなきゃいけないわけじゃないですか。SREチームの人たちはイチイチ細かい質の輩が多いのでやれ「そのワークロードのトランザクション量は？」とか「インスタンスサイズは？」とか聞いてくるわけですよ。…知らんがな。って思いますよね。そういう時は忘却武人にソイツらへ言ってやってください。

彼らの細かい反応はガン無視してとにかく上の言葉を言い続けましょう！なんならオプションの追加もしてやってください。

そうするとあなたの知らないSlackとかのチャンネルがザワつき始めます。

「超概算とは…？」
「"超"概算で松竹梅ってどうしたらいいんだ…」
「マジで頭沸いてんのかｗ」

これでそれなにり彼らの心を削ることは間違いなしです。
但し、どんな見積もりが出てこようと受け入れましょう。なんつったって「超概算」ですから。

手順書

最近はやれギットだパイプラインだインフラコードだとか言い訳めいたことをほざいて手順書作りをサボりすだす輩が増えてきましたよね。
そういう奴のレビューをする時は言ってやりましょう！

中にはこう言うとドキュメント管理ツールのリンク出してきたりMarkdown形式のファイルを見せてきたりする奴が出てくると思うんですよ。
言ってやってください！

これは大分心削れますね～多分SREの人たちはまさかExcelで手順書作らされるとは思って入社してないはずなので（ﾆﾁｬｧ
きっとあなたの知らないSlackとかのチャンネルではこんなやり取りされてますよ。

「何？コイツ平成からタイムリープしてきたの？」
「センスないからとっとと辞めろや」

はい、じわじわ効いてきていますね。

戻しのパイプライン

こっちがレビュアーの場合は彼らもぐぬぬしつつ従うしかないのでね、git add, git commitとかご丁寧にExcelに書いてくれると思うんですよ。わざわざCI/CDパイプラインの実行結果例のキャプチャもExcelの別シートとして参考に貼り付けておいてくれるはずです。でも変更手順だけじゃ足りないですからね。何かあった時どうするんだ？と。そういう指摘をすると彼らはgitのcommitを戻してパイプラインを再実行してどうたらとか言い訳めいたことを言ってくると思うんですよ。そういう時は言っちゃってください！

彼らはきっと言葉が詰まる筈ですぜ。きっとあなたの知らないSlackのチャンネルが盛り上がります。

「戻しのパイプラインｗ今年のトレンドワード来たｗ」
「コイツ分かってて言ってるのかｗ」
「そんなん初めて聞いたわｗ」

もちろん環境変更のExcel手順とは別のシートにして戻しの手順書を作らせてくださいね。指差し確認も前提条件に入れるよう漏れなく指摘してあげましょう！

インフラのせい

システムは開発が終わったらひと段落じゃないですからね。ユーザーに利用され始めてからが本番です！ここでSREチームの人たちが本領発揮するんですよ。シャレオツなダッシュボードをいそいそと作ってシステムの挙動を確認していつもと違う動きがあれば開発チームと連携して調査をする。…そこまでやっていても人間が作ったものですからね。障害はつきものですよ。ある日突然システムに全く繋がらなくなることもあります。そんな時はわざわざアプリケーション観点で障害調査なんてちゃちぃことやってないでSREチームにこの発言をぶん投げてやりましょう！

はいはい、大分来てますよこれは～。きっとあなたの知らないSlackのチャンネルがキ○レツ大百科のコ○スケのスタンプで一杯になります。

「お前は何を言っているんだ」
「キレてるだけならコイツの存在価値ないからとっとと失せろ」
「コイツに構ってる暇無いわ」

そうですこちらから言ってやった時には既にトラブルシューティングを始めているのがSREチームの人たちなんですよ。そんなのお構いなしにこうかましてやりましょう！

SLA100%

システムが一生一秒たりとも停止せずに稼働し続けることは現在のところなかなか難しいのでSREチームは運用設計で杓子定規にSLAを決めたがるじゃないですか？なんなら「パブリッククラウド自体にSLAの規定があるのでサービスとしてのSLAを教えてください。それを元にアーキテクチャを検討します。」とか言い出す始末ですよ。舐めてますよね？あなたが該当システムを担当するそれなりのポジションについている場合は大概運用設計まわりの会議やチャットでSREチームから定期的にヒアリングされると思います。その時は「ん～分からないから確認しとくねぇ」と返答するかチャットだと無視を徹底してください。個人メンションされても無視ですよ、無視。で、そのシステムが本当にローンチ直前になった時にこう言ってやればいいんです。

流石にイケイケなSREチームの人たちでも目上の人からそういわれたらしょうがないので渋々運用設計のドキュメントにその数字を記載しておくでしょうね。でも先述した通りシステムが一生一秒たりとも停止せずに稼働し続けることは現在のところなかなか難しいので例えばパブリッククラウドの急な障害やメンテナンスなどで数秒～数十秒停止することもありますよね。昨今流行り？の疎結合アーキテクチャ的な感じであれば痛くも痒くもないのですが大概オンプレからパブリッククラウドへ移行したようなシステムだと例えマネージドなKubernetesとかに乗せ換えてコンテナ化してたりしてもガッツリ密結合アーキテクチャなまんまだったりしますよね。そうなるとクラウドリソース側で数秒の停止があるとそのシステム全滅でーす！となることあります。こんな時責任の所在を明確にするための動きがあっても自責と認めてはダメです！例えパブリッククラウドのSLAの範囲内であってもですよ？SREチームが横目でこちらをﾁﾗﾁﾗ見てきたらこう言い放ってやりましょう。

きっとあなたの知らないSlackのチャンネルでは先述のあなたのチャットや議事録上の発言のキャプチャが貼られまくっていることでしょう。でも安心してください。権力の前では設計書上のSLAの記載なぞ落書きみたいなものです。

SREにやらせる

あなたがそれなりのポジションであれば担当しているシステムについてもっと上のポジションの方からやれコスト削減だ、運用の自動化をして工数を削減しろとか詰められることも日常茶飯事だと思います。本当に痛み入ります。でも最近は「運用」とか「自動化」とかのワードに尻尾を振ってくる奴らがいるんですよ。そう、「SREチームの人たち」です。なので上の方から詰められることがあれば腕を組んで偉そうにしながら（例えオンラインでも自分のカメラをオンにして）こう言いましょう。

はい！これで面倒ごとは奴らに流れていくぅ！例え奴らがこのことを知らなくても決まってしまえばこっちのもんです。これがSREチームに伝わる時にはあなたの知らないSlackのチャンネルでこう書き込まれるでしょう。

「コイツは何をもって勝手に決めてるんだ？」
「コイツからSREというワードが出てくるだけで反吐が出るわ」
「自動化したらコイツ自体要らなくなるやんｗ」

もうそろそろ転職サイトに登録し始める頃ですね～…あともう少しです！

DevOps

最近DevOpsってワード流行ってますよね。あなたももしかしたら自身は興味ないけど上の人から「これからの時代はDevOpsだぞ！」と無茶振りされているかもしれません。正直どうでもいいなと思いながらとりあえずDevOps的な何かを始めないと、とストレスを感じているかもしれません。安心してください。「SREチームの人たち」が全部何とかしてくれます。
早い話、SREチームに丸投げしちゃいましょう。まずは彼らを集めてﾊﾅﾎｼﾞしながら一言

そのまま立て続けに言っちゃいましょう。

もちろん組織が開発、SRE、運用と縦割りであってもDevOpsはツールですからね。関連ワードっぽいSREチームに良い感じのことを提案させればいいんですよ。
もちろんね、あなたの知らないSlackのチャンネルでこう書き込まれるでしょう。

「DevとOpsの意味分かっとる？」
「DevOpsはツール？コイツどこかの怪しいベンダーに騙されとるんか？」

まぁそんなこと愚痴りつつなんやかんやあなたを満足（~~掌で転がす~~）させる提案を持ってきてくれるのでﾊﾅﾎｼﾞしながら待ってましょう。
ここまでいくと余程のことがない限り退職届の執筆開始待ったなしです！お疲れ様でした！

まとめ

しっかりみんなで考えながら補い合いながら仕事しよう

もちろん本記事は全てネタです。
下記の記事のAnti-Good Inversion Method(AGIM)を取り入れて執筆しました。（取り入れたつもりです。）

本記事を通して言いたかったのは例えどんなところに所属していてもお互い尊敬し合える仕事をしよう、ということです。各自の得意分野は異なるので中途半端に知ったかをせずにそれぞれ不足していことを補い合えるのが理想ですよね！