SRE NEXT 2024に参加しました

こんにちは。CEOの@nari_exです。2024年以降、一番おいしかった食べ物は岩崎農園のとちあいかです。

Topotal(トポタル)はSREを主軸にした会社であり、国内でも有数のSREカンファレンスであるSRE NEXTには毎年積極的に参加しています。前年に引き続き、今年も多岐にわたって活動することができました。この記事では、カンファレンス当日のTopotalの活動をざっくりお伝えしたいと思います。

ブース出展

今年もGOLDスポンサーとして協賛し、ブース出展を行いました。ブースでは、Topotalが提供するインシデントマネジメントSaaSWaroom(ワルーム)のグッズの配布とデモによる機能紹介を行いました。

ブースの様子

また、来場者アンケートを集計したところ、インシデントマネジメントに関するツールがまだまだ普及していないこと、ドキュメントの自動生成とトレーニング機能について多くの期待が寄せられていることがわかりました。

この他にも、デモ後のディスカッションを通じて、オンコール機能への関心が全体的に高いこと、Waroomの既存機能にまだまだ改善点があることも認識できました。

アンケート結果

カンファレンスが行われた2日間ともブースは大盛況となり、今年もたいへん貴重な意見をたくさんいただくことができました。ありがとうございます。フィードバックをもとにWaroomをよりよいプロダクトにしていきたいと思います。

スポンサーLT

GOLDスポンサーの特典として、スポンサーLTの機会をいただいたので、CTOの@rrreeeyyyが「An Efficient Incident Response Training with AI」というタイトルで発表を行いました。

speakerdeck.com

この発表の前半では、インシデント対応のむずかしさに言及し、その1つの解決策であるインシデント対応訓練の実践には多くのコストがかかる問題を指摘しています。

そして後半では、課題の解決策として「AIを活用したCost-Effectiveなインシデント対応訓練」を提案した上で、Waroomのインシデント訓練機能とより発展的な訓練のアイディアを紹介しています。

補足: Waroomではインシデント訓練機能として、サービスのコンテキスト(システム構成やサービス特性)を加味して訓練シナリオを自動生成する機能シナリオに基づいたロールプレイ型の訓練をSlack上で進行する機能の2つを提供する予定です。

Waroomは単に効率化するためのツールではなく、使い続けることでインシデントマネジメントを漸進的に改善できるツールにしたいと考えています。その一手として、Topotalは発展途上である訓練領域の課題に着手し、インシデント対応の民主化を後押しするための機能を考案しました。

本LTが好評だったこともあり、ブースではトレーニング機能のデモ依頼をたくさんいただき、良いフィードバックを得ることができました。

来年のSRE NEXTでまたブース出展ができれば、今年のようになにか良い発表ができればと思っています。

セッション

Topotalからは @rrreeeyyy@yuuk1@nari_exの3名がセッションやパネルディスカッションを行いました。

セッション: 工学としてのSRE再訪

Topotalのテクノロジアドバイザーであるyuuk1さんによる発表です。SREに関する学術的な専門知識を踏まえた上で、未発見課題へつながる問いについて考察を深める本講演は、ベストスピーカー賞を受賞したことからもわかる通り、すばらしい発表でした。当日参加されていない方はぜひご覧ください。

資料

speakerdeck.com

ブログ記事

blog.yuuk.io

セッション: 組織的なインシデント対応を目指して〜成熟度評価と改善のステップ〜

本記事の著者である私の発表資料です。SRE as a Serviceの担当SREとWaroomのPdMを兼務する日々の過程で生まれた「インシデントレスポンスを段階的に改善するための道標はないだろうか」という悩みに対して、インシデントレスポンスの成熟度モデルを構築しながら対処した経験や知見を発表しました。

本発表の背景や裏話などはまた別の機会に書きたいと思います。不運にもyuuk1さんの発表時間帯と丸かぶりしてしまった本セッションでしたが、おかげさまで会場もほぼ満席でAsk the Speakerでは時間いっぱいまでディスカッションを行うことができました。

資料

speakerdeck.com

インシデントレスポンスの成熟度評価

インシデントレスポンスの成熟度評価

パネルディスカッション: SREの技術トレンド2024

@katsuhisa__@rrreeeyyy@yuuk1@deeeet の4名によるパネルディスカッションです。

Waroomのブースが大盛況だった影響で私は参加できなかったのですが、立ち見が出るほど盛り上がったようです。

感想

今年のSRE NEXTも非常に楽しかったです。それがなにより良かったと思っています。今回、私は参加者・スピーカー・ブース担当者の3つの立場で関わりましたが、いずれも不自由なく目の前のことに集中することができました。懇親会も大盛りあがりでしたね🍺

運営のみなさま、SREコミュニティのみなさま、すばらしいカンファレンスをありがとうございました。

まとめ

Topotalは今年もさまざまなシーンでSRE NEXTに参加・貢献しました。その結果、TopotalやWaroomをより多くの人に知っていただくよい機会になりました。本記事では大きく取り上げていませんが、COOの@kenta.hiSRE NEXTのCo-Chairを務めたこともコミュニティに対する大きな貢献の一つでした。

これからもTopotalはSREを主軸にしたスタートアップとして、Site Reliability Engineeringを加速させるサービスの提供はもちろん、コミュニティへの貢献も積極的に行いながら、業界の発展に貢献していきたいと思います。

今後ともTopotalをよろしくおねがいします🙏

最後に

おかげさまで、カンファレンス直後からさまざまな企業さまからWaroomのトライアルのお申し込みやデモの依頼をいただいています。この記事を読んでご興味が湧きましたら、以下のリンクから気軽にリクエストをしてください。

waroom.com

また、TopotalではSRE as a Serviceをともに提供するSREやWaroomを開発するバックエンドエンジニア(Ruby on Rails)を募集しています。SREのプラクティスを用いて世の中の開発・運用の現場を一緒に変革していきましょう。ご応募お待ちしております。

jobs.topotal.com

Waroom ロゴができるまで

Waroom ロゴができるまで

こんにちは Topotal CDO@sawa-zen です!2020年から Waroom の開発をはじめて四年が経ち、おかげさまで Waroom を使ってくれているお客様や知ってくれている方がだんだんと増えてきました。そこで皆さんにさらに Waroom について知ってもらおうということで、 CDO っぽい記事第一弾として Waroom のロゴができるまでについて語ろうと思います。

実は Waroom ロゴは僕が開発初期に勢いよく作ってしまったので社内メンバーも完成までの経緯をよく知りません。そのためこの記事は社内メンバーに向けての記事でもあります。

一般的なロゴの構成について

Waroom のロゴの説明に入る前に一般的に用いられるロゴの構成について説明します。 ロゴは「シンボルマーク」と「ロゴタイプ」の2つで構成されていることが多いです。

一般的なロゴの構成

なぜこの2つで構成されるかというと、シンボルマークを見れば会社を連想できるし、連想できない場合でもロゴタイプを読めば社名やプロダクト名がわかるといった合理的な構成になっています。ロゴタイプのみの場合もありますが、スマホの登場でアプリアイコンとしてのシンボルマークの用途が増えていきたことで、最近ではシンボルマークのある構成を多く見るようになりました。

Waroom ももちろんその構成に則っています。

なぜ「青」を使ったのか

「war room」や「インシデント」と聞いてまず連想するのは炎上している様子です。つまりは炎 🔥 です。そのため最初は赤色やオレンジ色などの暖色をイメージしていました。他にも緊急事態感を出すために黄色と黒の構成も考えていました。

ただ、インシデント対応をする場面はただでさえストレスのかかる場面にもかかわらず、使うサービスのロゴマークも黄色や赤でストレスをかけるのはいかがなものかと思い、暖色を使うのをやめました。

そこから「Resolved」を表す「緑」か、消化する「水」を連想させる「青」どちらかにしようと考えました。ただ、緑をロゴに使用してしまうと、そのプロダクトのプライマリーカラーとして使用することになります。緑は UI 上では「成功」や「決定」のような意味のあることが多いです。Waroom はインシデントのステータスを表現することを想定すると緑をプライマリーカラーとして使用するのは難しいと判断しました。

結果として青に落ち着こうとしていたところで、弊社代表の高村が「青が好きなのでプロダクトのロゴは青にしてほしい」と言われて完全着地しました。(本人覚えてるのかな)

具体的になぜあのカラーコード(#1765C1)になったかは当時のフィーリングで選んでいます。ただ、明度や彩度はWebサービスとして扱いやすそうなラインになるように選んだ覚えがあります。

シンボルマークになぜ消火栓を選んだのか?

正直シンボルマークはかなり悩みました。「war room」というプロダクト名なので「部屋っぽさ」や「チームで集って対応している感」を表現しようと四苦八苦しました。その痕跡を貼っておきます。

↑右下のやつは僕の中で仮決定したシンボルマーク

この時点ではまだ暖色にこだわっており、マークとしてもどれもしっくり来ることがなかったので考え直し始めました。

そこで、Waroom を使って対応している人たちの僕の中のイメージを絵に描いて眺めてみてみました。そのときの絵がこちら。

燃え広がっている炎に果敢に立ち向かう人々

コマンダーが指揮をとってレスポンダーが消火作業していてかっこいいですね。でも、ここに Waroom があるとしたらどこにあたるだろうか?と眺めていて気づきました。

このあたりじゃない?

あくまで対応者は人間であり、Waroom は消化活動になくてはならないインフラ的存在になっていてほしい。あのホースの先にあるとしたら消防車や消火栓なのでそのあたりをモチーフにしたいと考えました。ただ、消防車も消火栓も赤色ですが、消火栓はシルエットとしてシンプルでわかりやすく青にしてもさほど違和感が無いことに気づいたのでそっちの方向で詰めていきました。

最初はロボットの頭だったけどそれはボツに

だんだんできてきましたね。あと少し。

ロゴタイプは?

ロゴタイプは結構適当でした。出来上がったシンボルマークに対してマッチしそうなフォントを選んだ結果 Solway というフォントになりました。この時点ではバランスを整えるために文字詰めだけは行っています。

シンボルとフォントをそのままのロゴタイプを合わせた様子

最後の味付け

やや野暮ったい感じがあったので細かいラインを直しつつ、もう少しギーク感を出したく監視ツールなどでよく見る六角形を盛り込んで今のロゴが完成です!全体的に統一感が生まれましたね。

完成!

Topotal のロゴとテイストが違い会社全体で統一感が無いのはやや課題ですが、ロゴの商標登録もしているし、個人的には気に入っているのでしばらくは大きく変えることは無いと思います。以上が Waroom のロゴができるまでの流れでした!ありがとうございました!

最後に宣伝

インシデント発生時に Slack から離れること無く、効率よく対応するための SaaS、 Waroom(ワルーム) を提供しています。AI を用いて Slack の情報から自動的にインシデント概要をまとめる機能や、ポストモーテムを生成する機能など Slack を用いた機能が盛り沢山なので是非お試しください。

https://waroom.com/

youtu.be

Waroom Meetup #1 を開催しました

はじめに

こんにちは! Topotalのkenta_hi です。

このブログは、6月4日に行った Waroom Meetup #1の開催レポートについて書きます。 想定している読み手は次のとおりです。

  1. Waroom Meetup #1に参加した方に向けて、Topotalがどんな思いで開催したのか知りたい人
  2. Waroom Meetup #1に参加できなかった方に向けて、どんなイベントの雰囲気だったか知りたい人

それでは、始めます!

Waroom Meetup#1を開催しようと思った背景

Webサービスの広がりとともにSREが普及し、さまざまな企業のSREの活動内容は勉強会やイベントを通じて発信され、SREの活動のプラクティスを知る機会が増えました。

Topotalのメンバーも発信を行っています。

その中でインシデントレスポンスの領域だけは、各社が模索しながら改善を進めておりプラクティスの共有が徐々に増えてきたものの、発表の場がまだまだ少ないと感じていました。

インシデントレスポンスを共有する場が少ないのは、インシデントレスポンスの特性にあると思います。 過去は障害が起きないこと・起こさないことが重視されていましたから、ネガティブな発信になってしまう可能性があります。また、そのシステムごとの背景もあるため、仔細な説明が難しいのではないでしょうか。

しかし、昨今ではSREのプラクティスが浸透しエラーバジェットの概念が理解されたことで、インシデントの取り扱いが変わってきました。 こういった背景とTopotalはSREコミュニティへの貢献を1つの軸として活動していることも相まって、イベントを開催することに至りました。

Waroom Meetup#1 の内容

今回は第1回ということもあり、すべてのセッションを招待制で行いました。社内で登壇いただきたい方の候補をあげ、発信している情報を確認しました。

そこから考えた今回のテーマは、インシデントレスポンスの始め方から改善のプラクティスを集めることにしました。

この理由は、これからインシデントレスポンスを始める方にも、すでにインシデントレスポンスのツールを使っている方にも有益な情報になると考えたからです。また、インシデントマネジメントSaaSを展開するWaroomとも適していました。

このテーマにぴったりなWaroomを導入と共にインシデントレスポンスの整備をしたLuup @gr1m0hさん、内製Slack Appでインシデントレスポンスの改善を進めている10X @sota1235さんのおふたりにお声がけしました。

おふたりの発表資料は、インシデントレスポンスを現場で実践したとても興味深い内容でした。

資料は以下のURLからご確認いただけます。

Luupの開発組織におけるインシデントマネジメントの変遷 @gr1m0h

speakerdeck.com

内製したSlack Appで頑張るIncident Response@Waroom Meetup #1 / Incident Response with Slack App in 10X @sota1235

speakerdeck.com

ほかには、SREに関する論文の紹介を@yuuk1tさんに共有いただきました。

#SRE論文紹介 Detection is Better Than Cure: A Cloud Incidents PerspectiveV. Ganatra et. al., ESEC/FSE’23

speakerdeck.com

Microsoftがアラーティングに対して実地で調査して問題提起した内容になります。解説をいただきながら、共有いただくとより理解が進みました。このような論文紹介は、定期開催してもらいたいなぁ〜と思っています。

最後は、TopotalからWaroomの開発秘話と今後のアップデートについて@nari_ex から共有しました。

Waroomの開発モチベーションと今後のロードマップ / Waroom development motivation and roadmap

speakerdeck.com

「つらい」インシデント対応を無くすというワードがいいなと、私は思っています。

インシデントがなくなることはありませんが、言語化した課題(質と量、連携の課題)は解決できる問題です。

この課題が少しでも減っていくことで、インシデント対応から学びを得られる機会が増えていくと私は信じています。

最後の懇親会は、皆さんが思い思いに交流できていたように見えました。お酒を飲みながら、Waroomのデモをつまみに話が盛り上がったり、開発秘話を話したり、お互いの仕事の悩みを共有したりしていました。その後、2次会には14名の方が参加し、より深い話ができたのではないかと思います。

人と人とのつながりを生み出せたと感じ、開催して良かったなと思える瞬間でした。

次回にむけて

みなさま、アンケートにお答えいただき、いろいろなご意見をいただきました。アンケートの内容も加味しWaroomMeetup#2 を企画していきたいと思います。 次回は、今回できなかった公募の発表も募集したいと考えています。インシデントマネジメントの活動の知見がある方は、ぜひお声がけください。 次回の開催は、2024年9月〜10月頃の開催を予定しています。

最後に

イベントを運営するぞ!に注力しすぎて、Blogに載せられるような写真がない問題が深刻ですね。みんなで最後に集合写真撮るかとかできなかったのが個人的にはちょっと悲しいです。

次回は、司会進行かフォトグラファーをアサインしようと思っています。

jsx-slack で Slack App を開発すると幸せになる話

こんにちは。CDO@sawa-zen です。

Topotal では Waroom(ワルーム) という SaaS を作っており、 Slack App を使った機能もあるため Slack UI を構築する場面が頻繁にあります。

ただ Slack UI の開発は Web UI などの開発と比べると開発しづらく、なんとか解決できないかと悩んでいた中で見つけたのが jsx-slack でした。 結果として劇的に開発体験が向上したので今回は jsx-slack を使用するといかに幸せになれるかをご紹介します。

https://github.com/yhatt/jsx-slack

Block Kit のつらさ

まず jsx-slack の魅力を伝える前に現状の「つらさ」をお伝えします。 Slack UI を構築するには Slack が提供してくれている Block Kit という UI フレームワークを使用するのですが、これがなかなかにシンドい。。。

  • 1️⃣ 非直感的な JSON で UI を構築する必要がある 😢
  • 2️⃣ Block Kit Builder がやや使いづらい 😢

https://api.slack.com/block-kit

1️⃣ 非直感的な JSON で UI を構築する必要がある 😢

Block Kit は JSON 形式で UI を構築します。例えばこんな UI を構築したい場合の Slack API に渡さなければならない JSON データはこちら。

構築したい UI に対して記入する JSON の量が多く感じます。また JSON のままでは直感的にレンダリングされる UI のイメージが湧きづらいです。このサンプルはかなり簡素なものなのでまだギリギリイメージできますが、フォーム系のUIが加わるとより複雑化します。このJSONをメンテナンスしていくのはかなり骨が折れます。

2️⃣ Block Kit Builder がやや使いづらい 😢

1️⃣のペインを解消すべく Slack は Block Kit Builder というエディターを用意してくれています。Block Kit Builder を使えば、API Document を確認することなく Web UI からボタンを押すだけで JSON を生成できます。生成された JSON を右側に用意されているエディターから編集もでき、作成したUIを実際に自分の Slack Workspace に送る事ができるため便利です。

ただこのエディターの挙動があやしく、意図しないタイミングでコードが消えてしまったり、UNDOができなくなるタイミングがあったりと、使っていると「キィーーーー!」と叫びたくなる事が多々あります。ここに関しては今後の改善に期待です。

ここまでで現状の Slack UI 開発のペインがざっくりわかっていただけたと思います。

jsx-slack という名の救世主

これらを解決してくれるのがこの jsx-slack です。その名の通り jsx を使ってこの JSON を作成できます。この jsx-slack を使って記述することで多くのメリット享受できます。

UI をイメージしやすい 👍

百聞は一見にしかず。先程の例で言うと以下のようなコードになります。

JSON で書いたものと比較すると圧倒的に記述量が少なく、また自分のようなフロントエンドの開発に長く携わってきた身からすると jsx で記述されているだけで出来上がる UI がイメージしやすいです。

ただ、この「イメージしやすい」というのにはもうひとつ理由があります。

HTML ライクに書ける 👍

jsx-slack はなるべく HTML ライクに書けるように設計されおり、 pimgblockquote などの HTML タグをいくつか使用できます。そのため、より親しみ深いコードで記述できイメージがよりしやすくなっています。またHTMLの知識があるだけで構築できるため学習コストも少なく感じました。

REPL が用意されている 👍

jsx-slack にも Block Kit Builder のような、ちょっと試したい時のエディターが用意されています。こちらはプレビューやボタンからUIを追加する機能はありませんが、シンプルで使いやすいエディターと Block Kit Builder でプレビューするためのボタンも用意されているため快適に構築できます。

基本的には VSCode などでコードを書くことになると思いますが、ちょっと確認したい時にはかなり重宝します。

https://jsx-slack.netlify.app/#message

まとめ

もし既に Slack App の開発をされている方であれば jsx-slack の良さが分かっていただけたかと思います。TypeScript 以外の言語で Slack App を開発されている場合でも UI の構築だけ jsx-slack に切り出すだけでも開発体験が絶対に良くなると思うのでおすすめです!

是非 jsx-slack を使って楽しい Slack App 開発をしていきましょう!

最後に宣伝

インシデント発生時に Slack から離れること無く、効率よく対応するための SaaS、 Waroom(ワルーム) を提供しています。AI を用いて Slack の情報から自動的にインシデント概要をまとめる機能や、ポストモーテムを生成する機能など Slack を用いた機能が盛り沢山なので是非お試しください。

https://waroom.com/

youtu.be