$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

レビュータイムや定期的なissueチェックのためにGithubのissueを検索してSlackに投稿するCLIツールを作った

https://github.com/shibayu36/notify-issues-to-slack というツールを作ったので紹介です。

背景

はてな社内では各チームでレビュータイムという時間を設けていることが多い。その時間にチーム内のissueやPull Requestを全部見るという心がけをしている。レビュータイムについては昔に以下のような記事を書いた。
blog.shibayu36.org

一方レビュータイムを導入したとしても、レビュー依頼中のissueやPull Request一覧がSlackに流れてこないと、レビューやっていくぞという気持ちが高まらないことがある。そのためレビュータイムになったらレビュー依頼中のissueをSlackに流すツールを各チームでそれぞれ作っていた。

最近自分もまた同じようなツールを作ろうとしてしまった。しかし、みんな同じツールを作っているのは良くないと思い直し、このようにissueやPull Requestを検索し投稿するという汎用的なCLIツールを作りたいと考えた。

今回のツールでの投稿イメージ

コマンド一発でSlackに以下のような投稿ができる。

example

インストール

https://github.com/shibayu36/notify-issues-to-slack#installation を参照。go get/Docker/binary取得で使える。

使い方

基本的には-queryというオプションで検索クエリを指定することで、それにマッチしたものをSlackに投稿できる。-queryにはSearching issues and pull requests - GitHub Docsの全てのクエリが利用できる。

$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -query='repo:shibayu36/notify-issues-to-slack state:open label:"レビュー依頼"' \
    -text="レビューしましょう! @shibayu36" \
    -channel="review-channel" # slack channel to be posted

さらに-queryオプションはGithubでは対応していない相対時間も対応している。

$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -query='repo:shibayu36/notify-issues-to-slack state:open label:"レビュー依頼" created:<now-1w' \
    -text="レビュー依頼になってから1週間以上経ってるよ!そろそろしませんか? @shibayu36"
  • danger-filterや-warning-filterというオプションを使うことで、色付けも可能。一週間以上経っていたら赤色に、3日以上経っていたら黄色に色付けできる。
$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -query='repo:shibayu36/notify-issues-to-slack state:open label:"レビュー依頼"' \
    -danger-filter='updated:<now-1w' \
    -warning-filter='updated:<now-3d'

投稿時のアイコンやユーザ名ももちろんカスタマイズ可能。

$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -query='repo:shibayu36/notify-issues-to-slack state:open label:"レビュー依頼"' \
    -username='reviewiraikun' \
    -icon-emoji=':hamster:'

Github Enterpriseを使っているなら、-github-api-urlを使えばOK。

$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -github-api-url='https://ghe.example.com/api/v3'
    -query=...

投稿内容のカスタマイズ

もしSlackに投稿するときのタイトル部分や、それぞれのissue部分(attachmentの部分)をカスタマイズしたければ、-textオプションと-issue-text-formatオプションを使うことができる。こちらにはtext/templateの機能が使われているので、そのシンタックスが利用できる。今の所-textには[]github.Issue.として、-issue-text-formatにはgithub.Issue.として渡される。

例えば次のコマンドはレビュー依頼があれば投稿し、なければレビュー依頼はありませんでしたと投稿する。

$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -query='repo:shibayu36/notify-issues-to-slack state:open label:"レビュー依頼"'
    -text="{{ if . }}レビュー依頼を確認しましょう @shibayu36{{ else }}レビュー依頼はありませんでした{{end}}"

さらに次のコマンドは投稿するそれぞれのissueの文章をカスタマイズするもの。

$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -query='repo:shibayu36/notify-issues-to-slack state:open label:"レビュー依頼"' \
    -issue-text-format="{{.GetTitle}} ({{.GetCreatedAt}}に@{{.GetUser.GetLogin}}が作成)"

その他便利クエリ集

例として便利クエリもあげておきます。

これはレビュー依頼中でレビュワーがいないものはwarningに、さらに2日以上放置されているものはdangerに色付け。

$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -query='repo:shibayu36/notify-issues-to-slack label:"レビュー依頼" state:open' \
    -warning-filter="type:pr review:none" \
    -danger-filter=""updated:<=now-2d type:pr review:none"

これは「進行中」ラベルが付いているのにアサインが決まっていないものを通知する。

$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -query='repo:shibayu36/notify-issues-to-slack label:"進行中" state:open no:assignee' \
    -text='アサイン忘れてませんか?'

これは自分へレビューリクエストがついたものを投稿する。

$ notify-issues-to-slack -github-token=... -slack-webhook-url=... \
    -query='repo:shibayu36/notify-issues-to-slack state:open type:pr review-requested:shibayu36'

まとめ

今回はGithubのIssueやPull Requestを検索してSlackに投稿するというツールを作ったので紹介した。まだ雑に作っていてalphaクオリティなため、インターフェースは変わる可能性があるが、よければ使ってください。

https://github.com/shibayu36/notify-issues-to-slack

問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト

自分の置かれた環境で問題意識を感じることってありますよね。例えば

  • 上司全然ちゃんとやってくれないじゃん!最悪!
  • 会社にこういう問題あるじゃん!なんで直らないの!最悪!

みたいな感じ。

昔はこういう問題意識を持った時、自分で「良い状況に変える」ことに苦労をしていました。しかし、最近は自分の意識を変えることで「効率的に良い状況に変える」ことをしやすくなったなと感じています。そこで今回は、どのように自分が意識を変えたかということと、問題意識を感じた時に最近試しているアクションについて書いてみようと思います。

昔に自分がよくやっていたアクション

問題意識を感じた時、昔に自分がよくやってしまっていたのは

  • 飲み会の場で愚痴る
  • 上司に詰め寄る
  • 問題意識だけを提起する

というようなアクションです。このようなアクションをした時、良い上司はちゃんと話を聞いてくれて、実際に問題が解決することも多くありました。

最近の意識の変化

しかし今から思い返してみると、上記したようなアクションでは、効率的に良い状況に変化させられない場合もあるなと思い直しました。そこで最近は問題意識を感じたときは、効率的に良い状況に変化させるために、問題意識だけを提起するよりも良いアクションはないかと吟味してから行動しようと考えるようになりました。

このように意識を変えてみたところ、昔と比べてより素早く/より質もよく問題を解決できるようになってきたなと手応えを感じることが増えました。意識を変えたのは非常に良かったです。

どんなアクションを取ってみているか

ここからは意識を変化させてから、どのようなアクションを取ってみたかについて書いてみます。例えば以下のようなことをするようになりました。

  • 提案先を考える
  • 解決の一案も含めて提案する
  • 自分が良いと思ったことをエイヤッてやってしまう
  • 頑張るんで自分に任せてくれ〜と言っちゃう
  • 自分の領域外のこともやる
  • 他の人にやってほしいと思う行動を、自分がやる

提案先を考える

まず問題意識を感じたときは、どこに相談しようかな?と考えるようになりました。

例えばオフィス環境を良くしたい!と思ったときに、これ辛いんすよねってマネージャとの1on1で提案してしまいがちでした。けれど意識を変えて、オフィス環境を良くしたいって一番思っているのは総務部だろうから、そこに直接相談してみよ〜と思うようになりました。

このように自分が感じる問題意識を、実は自分よりも強く問題意識を感じていそうなところに提案するようにしてみたら、親身に相談にのってくれることが増えたなと感じています。

解決の一案も含めて提案する

提案先を考えた次には、この問題意識を解決するためのアイデアは何かないかな?ということを考えるようにしてみました。例えばこの会議室リモートで使いづらい!と思った時には、テレビの配置をこう変えたら良くなりそうでは?というアイデアも含めて提案するようになりました。

イデアも含めて提案すると、そのアイデアを草案として、もっとこっちのほうが良いのではないかとか、この観点はどうかとか、建設的な会話をしやすくなったなと感じています。

自分が良いと思ったことをエイヤッてやってしまう

提案をするのではなく、自分がエイヤッて勢いよくやっちゃうという選択肢も考えるようになりました。自分が問題意識を持っているのだから、自分が責任持ってやるぞ〜という世界観です。

エイヤッてやることは、かなり早く物事が進む方法だなと思っています。問題意識を持っている自分は熱量も高いから、たぶん一番素早く問題の解決が進むんじゃないかな。

そのかわり怖いですし、失敗することだって結構あります。けど結構おすすめです。成功したらめっちゃ褒められるし、失敗したとしてもその失敗から非常に多くのことを学べます。自分が致命傷を負わない程度にがんがん失敗していきましょうと思っています。

ちなみに成功率をあげるために最近僕がやっているのは、周辺の人に話を聞いて違う視点を得ることです。視野が狭すぎると失敗しやすいと感じているので、いろいろな方向から意見を聞いて成功率を上げるようにしています。ただし視野を広げすぎると今度は動けなくなるので注意。

頑張るんで自分に任せてくれ〜と言っちゃう

結構重要な問題だなと思った上で、これやるためにまとまった時間や権限や深い思考が必要だなと思ったときは、頑張るんで自分に任せてくれ〜と言っちゃうようにしています。任せてもらって時間や権限をもらえると、自分が行動できる範囲は非常に広がるので、問題を解決しやすくなりました。

これも「エイヤッてやってしまう」と同じような意味でおすすめです。「エイヤッてやってしまう」よりもさらに怖いけど、でも成功したときのリターンはすごく大きいし、失敗からの学びもより大きいです。

自分の領域外のこともやる

自分の領域外のこともやっちゃうようになりました。これは上司の仕事とか、これは他部署の仕事とか、そういうことを考えすぎると、解決する手段の幅が狭まってしまいます。領域外のこともやることで、難しそうと思った問題もさらっと解決することが増えました。

ただし、自分よりその分野の専門性が高い人への敬意は忘れないように注意しています。領域外のことをやりつつ、その領域の専門家には敬意を払ってちゃんとサポートしてもらえるように相談する。このようにすると効率的に問題が解決することが多いです。

他の人にやってほしいと思う行動を、自分がやる

他の人にやってほしいと思う行動があれば、まずは自分がやってみるということも心がけるようになりました。例えばプロダクトオーナーにもっとサービスのビジョンを語ってほしいと思ったら、まず自分が自分なりの考えでサービスのビジョンを語ってみる。そして僕はこう思っているのですが、プロダクトオーナー的にはどう思ってますか?と聞いてみる。自分がまずやることで、他の人にもお願いしやすくなったと感じています。

他人の行動を変えるのって簡単にはできないし、時間もかかる。でも自分の行動は一瞬で変えられる。なのでやってほしいと思っているなら自分でまずやるというのは良い選択だなと思っています。

ひとつ注意点

ひとつ注意点があります。僕は最初に「昔に自分がよくやっていたアクション」を書き、そのアクションでは効率的に「良い状況」に変化させられない場合もあるなと書きました。しかしこのアクションをやるなと言っているわけではありません。むしろやっていきましょう。

僕がマネージャをやっている時は、詰め寄られる/問題意識を提起されることよりも、全く相談されない/何も反応がないことの方が辛いのです。そのためマネージャ視点の自分は、愚痴る/上司に詰め寄る/問題意識を提起するみたいな行動もどんどんやってくれという気持ちでいます。やっていきましょう。

まとめ

ここまで問題意識を感じたときに自分が最近やっているアクションについて書いてみました。少し意識を変えるだけで「効率的に良い状況に変える」ことができるようになったと感じるので、意識を変えて良かったと思っています。最近やってみているアクションも参考になれば幸いです。

今回はどちらかというと問題意識を感じたときのボトムアップ的な考え方です。僕はマネージャのロールもやっているのでトップダウン的な考え方もまた書きたいなと思います。

おすすめ書籍

少し論旨とは違うのですが、問題解決というテーマで昔読んだおすすめ書籍も紹介しておきます。

ある問題が本当に重要な問題かどうかを知りたければこの本。

問題をどう解決するかの参考にはこの本。

アプリケーションは全員で監視する - 「入門 監視」を読んだ

最近話題になっていた「入門 監視」を読んだ。アプリケーションの監視をするための実践的なノウハウが詰まっていて非常に参考になる書籍だった。

この本では、アプリケーションを監視するための骨格となる考え方や、様々な層(フロントエンドからOSのメトリックまで)での監視の入れ方の実践的なノウハウ、さらには障害対応をスムーズに行うためのフローや障害の根本対応をチームで行えるようにするためのやり方まで書かれている。実践的なすぐに取り入れられるような内容が多く、「アプリケーションをどう監視したら良いか分からない!」「障害対応をもっとうまくやる方法はないのだろうか?」と思う人には参考になる部分が多いと思う。


個人的にこの本の中で一番良いなと思ったのは、

  • SREだけでなくアプリケーションエンジニアも含めたアプリケーションに関わる人全員で監視を考えていくことが大事
  • むしろアプリケーションエンジニアはそのアプリケーションに誰よりも詳しいはずなので、アプリケーション監視のデザインのための知識を誰よりも持っているはず

という話。最近僕のチームではSREがチーム内に所属するようになったためアプリケーションエンジニアにいろんな運用知見が伝えられた。それにより以前よりアプリケーションエンジニアも監視に詳しくなり自分たちで監視ルールを積極的に入れられるようになった。結果として、これまでアプリケーションの監視で漏れがあった部分が埋まってきていると感じている。この経験からこの本で書かれているような、アプリケーションエンジニアも含めて全員で監視を考えていくことに対する重要性に非常に共感できた

最近、監視はみんなでやろうという話を色んな場所で見かける一方、監視にアプリケーションエンジニアも携わるのが当たり前という認識が広まっているという状況にはまだまだなっていないなと感じている。そのためこの本をきっかけに、アプリケーションエンジニアとSREの監視に対する意識が統一され、監視を全員でやるのが当たり前という文化が広まると良いなと思った。


その他自分にとって参考になったのは以下のようなポイントだった。

  • 監視というとサーバのOSのメトリクスなどからやってしまいがちだが、できるだけユーザーに近いところから監視を始めるのが最適
    • HTTPのレスポンスコードやリクエスト時間など
  • 3章のインシデントの対応フローとインシデント対応の際に必要なロール。またアラートからその根本対応をするためのやり方


とにかく実践的な内容ですぐに取り入れられるので一読してみると良さそうです!

読書ノート

* 問題を解決するための適切なツールを組み合わせて使うのは良い。連携して使えないたくさんのツールを持つのはアンチパターン(例: ネットワークのレイテンシとアプリケーションのレスポンスの悪化を関連付けられない)。連携できて役割が異なるなら良い 343
* ツールは誰かが使っている、使っていたからという理由では選ばず、現在の状況で試し、評価することが重要 373
* オペレーションチームだけでなく全員が本番環境全体に責任を持つことが大事。ソフトウェアエンジニアはアプリケーションに誰よりも詳しいので、アプリケーション監視の仕組みをデザインするのには最高の場所にいる 426
	* 良い。実際にSREがチームに所属して、それによりアプリケーションエンジニアも監視を意識するようになった。それによりアプリケーションの監視の仕組み構築がもっと良くなったと感じる
* 監視サービスのコンポーネント: データ収集、データストレージ、可視化、分析とレポート、アラート 572
* データ収集の手法として、メトリクスとステータス情報を/healthに出力し、その出力を監視する手法がある 595
* まず監視を追加すべきなのは、ユーザがあなたのアプリケーションとやり取りをするところ 824
* 監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為。アラートは、この目的を達成するための1つの方法でしかない 938
* 誤報はとにかく減らそう。アラートをチューニングする簡単な方法が1つある。 1080
	* オンコール担当は前日に送られたすべてのアラートの一覧を作る
	* 一覧にひととおり目を通しながら、各アラートはどのように改善できるか、あるいはアラートを削除してしまえないか自問自答する
* 監視自体は何も修復してくれないので、基礎にあるシステムを改善する時間を持たなければならない 1107
	* オンコールシフト中、場当たり的対応をしていない時間は、システムの回復力や安定性に対して取り組むのをオンコール担当の役割にする
	* 前週のオンコールの際に収集した情報を元に、次の週のスプリント計画にシステムの回復性や安定性について取り上げる計画を立てる
* オンコールローテーションは出勤日に始めると、チーム内で引き継ぎがやりやすくなる 1107
* ソフトウェアエンジニアもオンコールのローテーションに入れる 1157
* インシデント管理のプロセス
	* 1. インシデントの認識(監視が問題を認識)
	* 2. インシデントの記録(インシデントに対して監視の仕組みが自動でチケットを作成)
	* 3. インシデントの診断、分類、解決、クローズ(オンコール担当がトラブルシュートし、問題を修正し、チケットにコメントや情報を添えて解決済みとする)
	* 4. 必要に応じて問題発生中にコミュニケーションを取る
	* 5. インシデント解決後、回復力を高めるための改善策を考える
	* s: 簡潔によくまとまっている
* 数分以上かかる本当のサービス停止には明確に定義された役割が重要 1157
	* 現場指揮官、書紀、コミュニケーション調整役、インシデント対応役(作業員)
	* s: 現場指揮官は最もアプリケーションに詳しい人(例えばテックリード)が適切、コミュニケーション調整役はマネージャ(例エンジニアリングマネージャ)が適切、書紀はだれでも、対応役は全員でやる
* フロントエンド監視にはリアルユーザ監視とシンセティック監視の2つのアプローチがある 1693
	* リアルユーザ監視とは実際のユーザトラフィックを監視のデータとして使うこと(Google Analyticsでのフロントエンド計測とか)
	* WebpageTest.orgのようなものはシンセティック監視
* Navigation Timing APIのタイムライン 1791
	* s: ブラウザのライフサイクルを知るのに非常に良い図
* フロントエンド監視では 1871
	* 実際のユーザが見ているページのロード時間を監視しよう
	* JavaScriptの例外を監視しよう
	* ページのロード時間をCIシステムから計測し続け、ロード時間が許容時間内に収まるようにしよう
* 分散トレーシングとは。リクエストに一意なリクエストIDを「タグ付け」することで、そのリクエストがどのサービスにアクセスしたか、各サービスでどのくらいの時間を過ごしたかが分かる 2290
* OS標準メトリクスから監視を始めるのはアプリケーションが動いているかどうかという重要事項と関連が弱いシグナルから始めることになるため、おすすめしない 2330
    * ただしトラブルシューティングの味方になるので、全システムで自動的に記録しアラートは設定しないくらいが良い
* 8章にはOSのメトリクスや他のよくあるコンポーネントのメトリクスの説明があるので、知りたかったら読むと良い 2330