生涯未熟

生涯未熟

プログラミングをちょこちょこと。

DevOpsDays Tokyoに初参加してDevOpsの祖を見た

先日開催されたDevOpsDays Tokyo 2024に参加しました!DevOpsDays Tokyo自体の参加が初めてで、琴線に触れるところが色々あったので書き留めていこうと思います。

参加前

自分の不勉強で申し訳ないのですがDevOpsDays Tokyoの存在を今まで知らず、Four keysについて調べていた時に以下のツイートを見つけて気になり参加を決めました。

こちらのセッション目的ではあったのですが、タイムテーブルを眺めて他の登壇される方を見ていると「おぉ・・・こんな豪華なカンファレンスを今まで見逃してたのか・・・」という後悔に近い気持ちを抱えつつ、速攻チケットを買った覚えがあります。

あとはDevOpsDaysを立ち上げて、DevOpsの祖と言えるPatrick Debois氏が講演されるということで、更に期待大でした。

聴講

事前に聴講スケジュールを立てたのですが、Four keysなどのメトリクスに関するセッションを中心に組み立てました。これは私が今SREとして取り組んでいることに直接関係するもので、すぐに現場に反映できる何かが得られると良いな〜という気持ちからでした。

ここでは聴講した中から幾つかピックアップして、烏滸がましいですが聞いた感想を書いていきたいと思います。

From Pilot to Transformation: Embracing the Reality of GenAI at Scale

Patrick Debois氏の講演で、AI × DevOpsについてのお話でした。

それぞれBuild・Delivery PIpeline・Operate・Business as usualの4つに分けた構成で、AIについての知識が殆どない私でも聞ける内容でAI特有のDevOpsにおける問題などのお話をされていました。

「様々なモデルが提供されている世の中だが、応答内容に実はジェンダーなどの属性におけるバイアスがかかっていないか?を気を付けよう」、「ユーザーに対してAIへの入力インターフェイスを設けても、キーワード検索に慣れてしまっているため"質問"を入れることに不慣れ」などのAIならではのお話。 「従来テストと違い、"結果との突き合わせ"を行うことができない。別のLLMに正しい答えか?をテストするやり方」、「一般的なサービスと同様、o11yについても気を払う必要がある」といったDevOpsとの兼ね合いの話をされていて、ほぇ〜・・・と声を上げることしか出来ませんでした。

※ o11yの文脈で紹介されていた www.langchain.com

AIは今後確実にコモディティ化していく領域だが、尖ったプロダクトは危険性を孕んでいて開発者・利用者として注意が必要ではあるといったことも仰られていたのが印象的でした。(画面上の全ての挙動を記録するAIソリューションを例に挙げて、セキュリティやプライバシーは大丈夫?といったことを言われていた)

自分が今後エンジニアとして従事していく中で確実にAI領域は触ることになるので(もう今ですらだけど)、少しずつキャッチアップしていきたいなと改めて思うセッションでした。

## DevOpsを体感!?DevOps大仮面の組織カルチャーお悩み相談室!

speakerdeck.com

DevOps大仮面のビジュアルにただただ圧倒されました・・・🤔(ビジュアルは中の人の記事を参照

takusamar.hatenablog.com

内容自体は組織カルチャーのあるあるお悩みに答えていくといったテイストなのですが、「サピエンス全史」を引き合いに出した回答をされていて、人間と人間の集合体はいつになっても過去の人間史に学ぶことができるな〜と楽しみながら聞いてました。

人類は突然変異による変革を中心に進化してきたが、それをサピエンス以後は「振る舞いによる変革」を行えるようになり、それが認知革命。そのため、"フィクション"を信じることで国籍・人種を超えた見知らぬ人同士でも協力が可能となったことから、組織の文化浸透もナラティブを有効に利用することが出来るというお話をされていました。
これは自分としても「たしかに!」と思う話で、理路整然としている提案内容であったとしても人は「それをすると一体どうなるの?」という不安に駆られてしまいます。それを払拭するために、他の方が実践して成功したという「成功譚」として吟遊詩人よろしく語ることも一つの変革をスムーズに行う手法でしょう。(ややもすると権威主義になっていまいますが・・・)

そんなこんなことを考えながら聞いていたら、最後に奥義フェニックスのポーズが始まって笑いながら聴講してましたw

SPI原点回帰論:事業課題とFour Keysの結節点を見出す実践的ソフトウェアプロセス改善

speakerdeck.com

こちらが冒頭でも紹介させていただいた参加のきっかけになったセッションです。

もうこの発表を聞くと生産性なんて言葉は簡単には吐けないな・・・ってくらいのボリュームで取り組まれているというお話で、アウトプットよりアウトカムという変遷が世の中的にも生まれているということが分かりつつも、「んじゃアウトカムってどう測ればいいの?」といった疑問が自分の中にありました。
その疑問への回答として「SODA構想」といったアーキテクチャを考え出し、その中で以下のようなレベルでメトリクスを取得し観測することでアウトカムを可視化できるといったことを仰られていました。

※スライド P.47より引用

これを見るとFour keysなんてほんの一部のメトリクスといった感じで、ビジネス側にまで踏み込んだメトリクスを取らないと真に生産性を測るなんてこと無理ですよね、というふわっと思っていたことを実践されていて素直に「スゲー!」と思いました。

後半はFour keysにより主眼を置いた話で、んじゃアウトプットは蔑ろにしていいのか?と湧いた疑問については「ロケットにおける推力とミッション」といった例えで答えられていました。
チームにとってアウトプットの推力がないと、そもそものアウトカムなんて得られようがありません。そんな大前提のアウトプットを測るためにFour keysは存在しますよねといった論調で、勿論Four keysで測った結果としてValue Stream Mappingを使ったさらなる掘り下げをされている話など測った後のNext Actionも含んだめちゃくちゃ身になるセッションでした!

サービス運用はボールを落とさない競技 : 2009年DevOpsDays の誕生と私の身の回りの話

speakerdeck.com

kawagutiさんによるDevOpsDaysを中心としたDevOps周辺の歴史をまとめたお話。
御本人も話されていましたが、これをDay1の基調講演にしていただきたかった内容でしたw

この中で、DevOpsDaysからDevOpsというものが端を発していったというのが存じ上げなかったので、話にあったアジャイルマニフェストのような最初に定義ありきのものかと思っていた自分にとっては驚きでした。
「コミュニティから生まれた実践者の概念である」といったものがDevOpsで、生まれた時から時代が進み、クラウドプラットフォームが当たり前の今の時代にとってはDevとOpsの境界線もより曖昧になりつつあると思います。

また、Flickrにおけるツールと文化の話も非常にSREと同じコンテクストでスッと理解することができました。こういう時代背景から継承され、発展してきた概念なんだなぁ・・・と。

最後に大事な言葉として仰られていた「相手が異なるスキルを持つことを尊敬する。相手を信頼して、ノブとレバーを渡す」は本当にその通りだと思うし、改めてこの身に刻みつけておかないとな、と思う言葉でした。

まとめ

長くなってきたのでセッション毎のまとめはこのあたりで〆。他にもカケハシ社さんの立ち上げ期から組織としてのより成長を促すための仕組み作りや、Google Cloud Japanの方のセッションでの「SREとはGoogleでのDevOpsの実践のことを指します」といった言葉だったり、Patrick Debois氏のインタビューセッションでの「DevOpsとは"組織の対立を解決する"こと全てに対しての取り組みのことです」といった言葉などバッシバシ心に刺さるセッションが多くありました。

来年も参加したいなと思うカンファレンスでした!運営に携わった方、スポンサーの方、登壇された方、全てに感謝🙏🙏🙏

SREに触れて「いろいろやろうぜ」のモードになった

SRE界隈の隅っこでワチャワチャやっているしょっさんです。
今色々やっているコミュニティ活動についてのお話を書き留めておきたいなと思ったので、ここにパパッと書いていきます。

今までについて

今までのコミュニティ活動の関わりについては以下のしずかなインターネットの記事として書きました。

sizu.me

そんなこんなで「ゆるSRE勉強会」の運営に関わらせていただいているのですが、せっかく再びコミュニティ活動始めたなら色々やってみっか!ってことで色々走らせてみました。

SRE Magazine

SREに関する記事を探すと様々なところに散らばっており、SRE Weeklyみたいな集約された場所があると面白いよな〜ということでエイヤの精神でやってみました。

sre-magazine.net

るびま」を参考に構成しているWebマガジンなのですが、最近第1号が発刊することができました。で、始めるにあたってのもう少し詳しい話はこちらに巻頭言として書かせていただきました。

sre-magazine.net

正直な話、皆様のご厚意による寄稿で成り立っているので定期的に発刊出来るか怪しいところはあるのですが、出せなくなったところで誰にも迷惑はかからないのでゆるゆると続けていきたいなと思います。

もしこれを読んで寄稿していただける方がいましたら以下フォームからお知らせください。(軽い内容で全然良いので!)

docs.google.com

SRE Kaigi

こちら目下進めている取り組みなのですが、SRE KaigiというSREのカンファレンスを開催しようとあくせく動いております。
SRE NEXTという超巨大カンファレンスがあるので要らんやーんという声も聞こえてきそうですが、もう一個カンファレンスあってもええやーんというお気持ちでやっております。

正直、初めてカンファレンス主催なんてやるので果たして上手くいくかどうか分からんですが、先人の方たちの残してくださっているモノに縋りながら何とかかんとかやっとります。感謝しかない🙏

techbookfest.org

こういった技術カンファレンスに関する手引書もありますし(穴が空くほど読んどります)

findy.connpass.com

最近だと、こういう猛者の主催者の方の生の声を聞く場もあり、非常に助かっております。タスカルタスカル...

万が一、上手く行った暁には続けていきたいな〜と思いますのでSREsの方や、興味あるよ〜っていう方は是非参加してみてね!よろしくね!!

Terraformに対応していないRemote ConfigをなんとかIaCしてみた

優先度の関係から長らく着手していなかったIaCタスクを進めていたのですが、開発メンバーと1on1した時に「Remote ConfigをIaCして欲しい」と要望を受けました。
たしかにコンソール上からコンフィグいじるの嫌だよな〜というのは薄っすら感じていたのですが、これを機になんとかしてみることにしました。

google-betaにない!!

Terraformにはproviderがありますが、Firebaseのresourceを扱うためにはgoogle-betaというベータ版のproviderを利用する必要があります。

registry.terraform.io

んじゃこれを使えばめでたしめでたし、とはいかず確認したところFirebaseの対応しているresourceの少ないこと少ないこと。
対応しているのは以下になります。

  • Firebaseプロジェクト
  • プロジェクトのロケーション
  • Firebaseアプリ
  • Firebase Realtime Database
  • Cloud Firestore
  • Cloud Storage for Firebase
  • Firebase セキュリティ ルール

これだけになります。はい、Remote Configがありませんね・・・

無いならなんとかしよう

まず、この時点でTerraform resourceとして管理するのは諦めました。無いなら仕方ない。
ただ、希望の芽としてFirebase CLIの存在があります。次は、こちら確認してみましょう。

firebase.google.com

デプロイはありませんね😇

ここまで調べたところで8割くらい無理なんじゃないか?と思ったところで、monoさんがzennに書かれていたこんな記事を見つけました。

zenn.dev

おぉ!希望の芽が再び!ということで、プログラム経由で更新することになりました。

デプロイパイプラインを作ろう

さて、プログラム経由で更新するということでCloud Functionsを使ってデプロイをするパイプラインを組んでみました。
概念図はこんな感じになります。

  • Remote Configの内容をコードに書き起こしたものを編集し、コミットする
  • コミットが通ればGitHub Actionsが発火し、Cloud Functionsに変更した内容を渡して実行する
  • Cloud Functionsで渡した内容を元にRemote Configへデプロイする

こんな感じの流れになります。

実装

GitHub Actions

まずはGitHub Actionsの実装です。前提として弊チームのRemote ConfigではJSONのみ扱っているため、それに合わせた実装となっています。

JSONを2つに分けている理由ですが、Remote Configのテンプレートを確認するとコンソールでの設定画面と違い、

{
  "parameters": {
    "info": {
      "defaultValue": {
        "value": "[ここがいつも設定しているコンフィグ情報]"
      },
      "description": "",
      "valueType": "JSON"
    }
}

このような形式で、 value にコンソール画面でいつも設定するようなコンフィグ情報が記載しています。
ただし、この value にはJSON文字列が入っており、視認性が悪いため修正するのにコストがかかります。そこで、テンプレートの土台となる部分本来の設定したいJSON文字列の部分とでJSONを分けることにしました。

workflowの中でも書いていますが、プロジェクト配下に github_actions/deploy-firebase-remote-config ディレクトリを置き、その中に config.json , info.json の2ファイルを置いております。 config.json がテンプレートの土台で、 info.json が設定したいJSONとなります。なので、開発チームが触るときには info.json を編集し、コミットするという流れになります。

コード自体は難しいことはしていませんが、jqを使ってゴニョっと2ファイルをくっつけているといったところが全てですね。

Cloud Functions

次に、Cloud Functionsの実装です。こちらはmonoさんのコードから大きくは変わらないのですが、こんな感じになりました。

credential権限を付与したサービスアカウントのJSONファイルの内容を、 databaseURL には https://[プロジェクト名].firebaseio.com を入れてください。前者についてはキチンとSecret Managerで管理するようにしましょう。
あとはよしなにデプロイ結果が分かるようにSlack通知を飛ばすようにしています。

おわり

これでRemote Configへのデプロイパイプラインが組めました。めでたしめでたし。
ありがたいことに開発チームから「便利になった!」という声もいただけて、やってよかったなぁとなったタスクでした。

SRE観点での技術負債 懺悔会 2024 に登壇しました

今回は御縁があってKDDIアジャイル開発センター(KAG)さんとMIXIの合同イベントに登壇いたしました。

mixi.connpass.com

今回のテーマが「SRE観点での技術負債」ということで、私の方からは以下のようなお話をさせていただきました。

speakerdeck.com

このブログではいつものようにライナーノーツとしてお伝えしきれなかったところなどを書いていこうかなと思います。

技術負債とは?

まず、このイベントのテーマである「SRE観点での技術負債」ってなんだろう?と引っかかったので、ここをブレイクダウンしていかないと自分の中でブレてしまいそうだなと思いましたので、技術的負債の定義を経てSRE観点の技術的負債の定義からさせていただきました。

技術的負債については色々な説があると思いますが、なるたけ新し目の説を扱おうということで(古いと時流と合わない可能性が高い)、「Defining, Measuring, and Managing Technical Debt」というGoogleで研究職をやっているCiera Jaspan, Collin Greenの両氏の論文を論拠の土台とさせていただきました。

www.computer.org

スライドでも述べましたが、この論文は技術的負債のカテゴライズ・測定・管理について研究した結果であり、これを基にGoogle社内で数年に渡って改善を行った結果として技術的負債は減ったようです。(とはいえ定量的な数値などが提示されていないので根拠が薄い)

さて、ではその技術的負債の種別とはどのようなものがあるのでしょうか?Google社内で専門家に対してのヒアリングを行った結果、以下の10個のカテゴリが判明しました。一覧の説明を少し手直ししましたので、ここで改めて掲示しておきます。

  1. 移行が必要なモノ、または進行中のモノ:スケーリング・依存関係・非推奨などが要因で移行をしなければいけないが、していない or 進行中
  2. ドキュメント:ドキュメントが足りていない、完全ではない、見つけにくい
  3. テスト:テストが足りていない、脆弱である(Flaky Testだったり)
  4. コード品質:適切な設計がされていない、プロトタイプ/デモ版のままである
  5. 廃止・放棄されたコード:廃止されたり、利用されていないデッドコードが残っている
  6. コードの劣化:時間経過とともにリファクタリングが必要になったコードが残っている
  7. チームに必要な専門知識が不足:離職・移動によって人材が不足していたりチーム内で知識を共有する場がない
  8. 依存関係:依存先の不安定さ、変化に対する耐性がない、または管理不足である
  9. 移行の失敗か、放棄:2つのバージョンが並列で動いている
  10. リリースプロセス:リリースプロセスやリリースの監視に対して更新、移行、保守をしていない

この10個のカテゴリがGoogle社内でのインシデント発生要因になった頻度順に並んでいます。つまり、移行をサボっていたことによるインシデントが一番多いということですね。

このように大別された技術的負債を測定して、管理しましょうということが書かれているのですが、そちらの内容の詳しいことは論文をご参照ください。

専門知識の不足については、「プロジェクトコードでTODOコメントが存在することはコード劣化の可能性があり、専門知識が不足している可能性もある」と書かれてもいて、コード劣化と密接な関係にあるというカテゴリは別だが因果関係が近しいパターンもあるようです。

この前提を基に、SRE文脈に変換したのがスライド上に載せてある一覧ですね。

ここで大事なことは「複数の視点を持ちましょう」ということです。プロダクトコードについてのみではなく、自分たちが作ったプラットフォーム・ツール・仕組みについても技術的負債の意識を持たなければいけません。

口頭で喋ったことの補遺

ドキュメントの項で説明したのですが、GitHubCopilot for Docsは期待していたのですが去年の12月に出たプレビュー終了通知には何の説明もなく非常に残念ですね・・・

GitHub Next • Technical Preview Sunsets

こういったAIを利用したドキュメント管理には期待をしているので、ベスト版がどなたかによって確立された際には徹底的に真似していきたい所存です。

コード品質ではオライリーソフトウェアアーキテクチャメトリクスの話を少し挟みました。

www.oreilly.co.jp

こうったコード品質メトリクスを静的解析し、結果をPRに貼り付けていけば品質向上の意識付けになるんじゃないかな〜というお話でした。

おわり

今回、登壇させていただきましたが他の登壇者の方々の発表内容の方が数段面白く、正直自分の実力不足を感じました。
もう少し、定義の部分はサッと終わらせて個々にフォーカスした方が面白かったのかな〜とか色々考えましたが、反省は次の登壇に活かしたいと思います💪

MIXI TECH DESIGN CONFERENCE 2024 に登壇しました

去年に引き続き、今年も社のカンファレンスに登壇させていただけました。

techcon.mixi.co.jp

去年と違い、今年はオフラインで会場にいらっしゃった方の前で初めて体験するパネル・ディスカッション形式ということで非常に緊張いたしました。

この記事では喋ったことの補遺というかライナーノーツみたいなことを書いていこうと思います。

他のチーム、職種の方との連携のコツ、取り組み

自分回答はこちら

「職種ごとに目線が違うのでそこを意識すること。非エンジニアの方とやり取りをする場合にはエンジニア間でしか通じない単語などを使わない。あとはベタにteam geekにも書いてあるHRTを大事にする。」

会場でも話しましたが、目線を揃えるということはサイトリライアビリティワークブックの18章にある「目標を揃える」と同義です。SREsが信頼性を尊ぶように、QAチームなら品質、ビジネスチームなら売上が目標となるはずです。
そこをお互いの目標が達成されるように目の前の課題などを乗り越えていく必要性があり、そこを対話によって目線を揃えていくことが大切だと考えているわけです。

sre.google

また、私は小さなベンチャーにいた経験があったので他職種の方と喋る機会が一般的な企業よりも多くありました。その中で培ったコツとして「エンジニア間でしか通じない単語などを使わない」がありました。意外な単語も思い返してみればエンジニア由来だな、というものがあるので一度頭の中で洗い出してみると小さな発見があるかもしれません。

HRTは有名すぎるエッセンスなので特に付け加えることもないですね。社会人として当たり前に身に着けておくべき教養です。

こういったことを意識して接することで、「SREingをやる人」という基本的な認識を持ってもらいつつも、「気軽に相談できる信頼できる仲間」として認知してもらえることを目指すのが良いのかなと思います。

SREの重要性をどう理解してもらうか

自分回答はこちら

「お題目だけの羊頭狗肉と思われないように開発チームにとっての重要なところからSREingを始めてみる。それでも伝わらないなら根気強く重要性を説明し、示していく」

モデレーターの清水さんから「開発チームにとっての重要なところって何?」という質疑がありましたが、開発チームはサービス価値を迅速にユーザーに届けることが重要で、そこに関して一番影響に寄与できるのがCI/CDですね。という応答をしました。

SRE in the Real worldのお話を挙げたのですが、ここでも「最初に始めるべきはdevinfra / relengだ」と述べられており、devinfraはDX(developer experience)の向上を狙った環境作り、relengはRelease Engineeringなので、CI/CDはまさにですね。

blog.relyabilit.ie

SREの人数規模による施策の違い、苦労や工夫など

自分回答はこちら

「一人でSREを実践していますが、リソースがとにかく足りないのでタスクの優先度決めはシビアにやる必要があります。あとはリソース不足の解消手段として開発チームを積極的に巻き込んでいくことです」

こちらも「優先度決めをシビアにやるためのコツはあるか?」という質疑を頂きまして、「コツというか指標はあって"ビジネスインパクトに影響するか?"が第一で、それ以外はチーム全体の影響度の高い低いで決める」と少しボヤッと答えました。
正直、チーム全体の影響度って何だよと思われた方いらっしゃるかもしれませんが、SREsのみに影響が偏るタスクよりもSREsと開発チームのお互いに影響が及ぼされるようなタスクを優先しましょうといった意味合いでした。例えば、「four keysの整備」はどちらかといえばSREs寄りのタスクで、それよりも「リリースサイクルの高速化」みたいなタスクの方を優先度高くしております。

何故そうしているのか?については、開発チームを巻き込むということをやるにあたって開発チームからの信頼貯金を貯めたいという側面が強いです。一人で全てのタスクをこなすといったことは無理に等しいので、貯めた信頼貯金を取り崩しながら開発チームにもSREingに積極的に関わってもらうようにする、といったことが非常に大事になってくるのです。

MIXIのSREでよかったこと

自分回答はこちら

「相談できる人が多いことですね。自分よりも優秀で優しい方々が多く、そこまで緊張せずに相談事が出来るのが素晴らしいです。直近の具体例だとDMARC対応ですぐにSlackチャンネルが立ち上がって助かりました。」

これは自社イベントだから盛って喋ってるんでしょ?と思われるかもしれませんが、誇張なしにそう思ってます。助けられてばかりではいけないので、自分も助ける側に回ろう!としてくれる方も多いので、助けて助けられる相助相譲が文化として根付いているのが本当に良いです。

おわり

というわけで、初めてのパネル・ディスカッションは何とかこなすことができました。また来年もカンファレンスに登壇できるといいな〜。