この記事は corp-engr 情シスSlack（コーポレートエンジニア x 情シス） Advent Calendar 2019 の12/24の記事っす。
AdventCalender参加時前後、ちょっとしたチェック処理をブックマークレットでサラッと書いてほいっと渡したらそれなりに反応をもらえた、という出来事があったので、あれ？割と知らない人いる？と思ったので、それ書くつもりだったのですが
当時（今もですが）、絶賛採用強化中だったので顔売ろう/知ってもらおうと思い、初CfP応募してみたんですがあえなく桜散ったということで、供養の為に話そうと考えていた内容を書こうと思います。
なお、Backlogについてのことを書くので、つかってねーわ、な方はふーん程度でご笑覧ください。
詳細は各所に飛び火しそうなので割愛しますが、プロジェクトに対して参加させるユーザの誤登録が発生したことがありました。
最初に説明しておくと、Backlogの利用規模はこんな感じです。
しばらく前に調べた数なので更に増えてるかもしれませんが、だいたいわかっていただけるかなと思います。
かなり昔から利用している、顧客<->社員で案件のBTS/プロジェクト管理として利用、社内のみのプロジェクト等でも使ってる、といった澱がたまりまくってることは想像に難くない状況だと思います。
そんな中で起きた事件だったので、もうこれはどうにかするしかない、ということにあいなりました。
Backlogのプロジェクトに対して変更する場合、登場人物として
がいます。当時のフローとしては
となっていました。
このフローの問題点は、依頼内容が意図通りの設定がされているかどうかのチェック機構がない。
もちろん人によっては連絡をもらった時点で確認している人もいると思いますが、水は低きに流れ…なので、そこはお察し。
ただ「依頼者は設定後、依頼内容が正しいかどうか確認してください！」なんてこと言った所で、浸透しないでまた同じようなことが起きる、ということはわかっていたので、次のような仕組みを作りました。
まあ管理者のオペミスまでは考慮できるはずがないので、そういう意味も含めてですが。
（一応貼ってみましたが、モザイクだらけでよくわからないっすね）
なお、上記シーケンス図ではわかりやすく？DBとしていますが、ただのspreadsheetです。
つまりジョブはGASです。（typescript/clasp/webpack/jestです）
これを作ったときに思いましたが、Backlog側でバリデーションを設定できる的な機能があったらよかったのに…だるいわ…って思いました。
また今はプロジェクトの情報収集はスケジュールさせてますが、おいおいはWebhookでやったほうがいいなあ…って思ってます。
お気づきかもしれませんが、これは仮に誤登録があった場合、最大30minは誤登録された状態を許すことになってしまいます。
つまり、登録時点の対策が盛り込まれていません。
まだ開発中ですが、次の様な対応を想定しています。
β版は概ねできたので、これからβテスト走らせるかーといった状況です。
こんな感じ
まあChromeは野良Extension撲滅運動とかも去年？とかやってたし、Backlog側もUI変更する可能性は当然あるので、今後どうなるかわかりませんが…
取り急ぎそんな所で。
今回はBacklogのユーザ管理について焦点を絞って対策を書きましたが、触れてない箇所に対しても地味にコツコツやってたりします。
SaaSも結局道具なので、どう使うが重要だなあと日々感じています。イケてるSaaS入れたら終わりとかそんなんないからマジで。
だいぶ割愛したので、細かい所とか意味わからんとか興味ある箇所があったら連絡ください。
答えられる範囲で答えます。
明日は滝澤佑貴さんのトリです。
AdventCalender参加時前後、ちょっとしたチェック処理をブックマークレットでサラッと書いてほいっと渡したらそれなりに反応をもらえた、という出来事があったので、あれ？割と知らない人いる？と思ったので、それ書くつもりだったのですが
ҟҽղհɾօ ʍօɾ@_john_doe_
だめだったー、残念 https://t.co/p32JhxbTzo
2019/12/09 23:05:52
当時（今もですが）、絶賛採用強化中だったので顔売ろう/知ってもらおうと思い、初CfP応募してみたんですがあえなく桜散ったということで、供養の為に話そうと考えていた内容を書こうと思います。
なお、Backlogについてのことを書くので、つかってねーわ、な方はふーん程度でご笑覧ください。
# インシデント発生
詳細は各所に飛び火しそうなので割愛しますが、プロジェクトに対して参加させるユーザの誤登録が発生したことがありました。
最初に説明しておくと、Backlogの利用規模はこんな感じです。
- プロジェクト数: 2000++
- ユーザ数: 10000++
しばらく前に調べた数なので更に増えてるかもしれませんが、だいたいわかっていただけるかなと思います。
かなり昔から利用している、顧客<->社員で案件のBTS/プロジェクト管理として利用、社内のみのプロジェクト等でも使ってる、といった澱がたまりまくってることは想像に難くない状況だと思います。
そんな中で起きた事件だったので、もうこれはどうにかするしかない、ということにあいなりました。
# 対策
Backlogのプロジェクトに対して変更する場合、登場人物として
- 依頼者
- 管理者（権限としてではなく、依頼された内容を設定する人。依頼内容が妥当かの判断はできない）
がいます。当時のフローとしては
- 依頼者がBacklog経由で作業依頼する
- 管理者がプロジェクトの作成をしたり、ユーザの追加/削除の作業をする（チームの対応も含む）
- 作業完了後、管理者が依頼者に対応済みの連絡をする
となっていました。
このフローの問題点は、依頼内容が意図通りの設定がされているかどうかのチェック機構がない。
もちろん人によっては連絡をもらった時点で確認している人もいると思いますが、水は低きに流れ…なので、そこはお察し。
ただ「依頼者は設定後、依頼内容が正しいかどうか確認してください！」なんてこと言った所で、浸透しないでまた同じようなことが起きる、ということはわかっていたので、次のような仕組みを作りました。
まあ管理者のオペミスまでは考慮できるはずがないので、そういう意味も含めてですが。
- 基本的には上記フローはそのままで、DBに対する更新作業を作業者側のタスクとして追加
- タスクは、許可する外部のユーザのメールアドレスをホワイトリストとして正規表現で設定、プロジェクト単位で設定
- プロジェクトの情報は1回/30min収集（新規追加/更新）
- 1回/30minで検査するジョブが発動、プロジェクトの参加ユーザの情報を取得して検査、ホワイトリストに合致しないユーザを検知した場合slackに飛ばす↓
（一応貼ってみましたが、モザイクだらけでよくわからないっすね）
なお、上記シーケンス図ではわかりやすく？DBとしていますが、ただのspreadsheetです。
つまりジョブはGASです。（typescript/clasp/webpack/jestです）
これを作ったときに思いましたが、Backlog側でバリデーションを設定できる的な機能があったらよかったのに…
また今はプロジェクトの情報収集はスケジュールさせてますが、おいおいはWebhookでやったほうがいいなあ…って思ってます。
# V2の話
お気づきかもしれませんが、これは仮に誤登録があった場合、最大30minは誤登録された状態を許すことになってしまいます。
つまり、登録時点の対策が盛り込まれていません。
まだ開発中ですが、次の様な対応を想定しています。
- ブラウザの野良Extensionを開発して
- 上記のDBとAPIで連携して、妥当性を評価
- 明らかにNGの場合はプロジェクトに参加させない
β版は概ねできたので、これからβテスト走らせるかーといった状況です。
こんな感じ
まあChromeは野良Extension撲滅運動とかも去年？とかやってたし、Backlog側もUI変更する可能性は当然あるので、今後どうなるかわかりませんが…
取り急ぎそんな所で。
今回はBacklogのユーザ管理について焦点を絞って対策を書きましたが、触れてない箇所に対しても地味にコツコツやってたりします。
SaaSも結局道具なので、どう使うが重要だなあと日々感じています。イケてるSaaS入れたら終わりとかそんなんないからマジで。
だいぶ割愛したので、細かい所とか意味わからんとか興味ある箇所があったら連絡ください。
答えられる範囲で答えます。
明日は滝澤佑貴さんのトリです。
