1. h173.club
  2. 016: 安定したサービス提供の..
2022-09-02 15:58

016: 安定したサービス提供のための改善レポート制作秘話

kenchanとtakapiの二人で、カラーミーショップで2021年10月から公開している「安定したサービス提供のための改善レポート」について、公開するようになったきっかけや、作成のプロセスについて話しました。

00:02
ひとなみクラブは、GMOペパボEC事業部の2人の高橋が、社内の出来事や最近気になっている技術について話すポッドキャストです。
みなさんこんにちは、くんさんです。
こんにちは、たかぴぃです。
ちょうど一週お休みをいただいてて、夏休みだったので収録とか、あと編集とかもしなかったので、
ちょうど一週空いて公開になってるんですけど、
たかぴぃは夏休み、どっか行ったりなんかしたりしました?
そうですね。ちょっとご自身的にちょっと微妙なところがあったりするので、外には出かけてはないですね。
そっか。
はい、今年はそうですね。
なんかこう、風潮的に旅行してる人とかも、なんか増えてきたりとかはしてはいるんですけど、
まだちょっと怖いところはあるなっていうところがあるので、そうですね。
今年は基本は家でみたいな感じで過ごしてましたね。
なるほど、確かに。私も結局どこにも行かなかったっていうわけではないですけど、
もともとあった予定で少し外に出たぐらいで、あんまり旅行みたいなのもしませんでしたし、
実家に帰るみたいなのもなかったので、ゆっくり過ごしましたね。
なるほど、なるほど。
まあ、夏休みの話題はそれくらいにして、
今日はカラーミショップで取り組んでいるアウトプットについて、
一つ話してみようかなと思ってきたんですけど、
はい。
ちょうど1年前ぐらいですかね、9月ぐらい、9月じゃないか、その前でしたっけ?9月か。
9月、10月あたりですかね。
9月、10月ぐらいに安定したサービス提供のための改善レポートっていうのを出したんですよね。
で、これ何かっていうと、
そうですね、私たちがよく目にするものだと、GitHubとかAWSで大きな障害とかが起きたときに、
彼らがポストモーテムみたいなものを公開してるんですよね。
こういう理由でこれだけの時間落ちて、原因はこれで、
こういう対策をしたので、次からは同じような問題は起きませんみたいなのを公開してるんですけど、
これに似たようなものをカラーミショップも出してみようっていうのをちょうど1年前から始めていて、
今は市販機に1回ですかね、
全市販機の状況みたいなのをレポートするっていうのを、
ちょうど前回出したのが6月か7月ぐらいで、
ちょうど1年4回続いたので、
ちょうど1年これで続いたことになるんですけど、
これについて少しどういった背景があったのかとか、
どういう体制で今レポート出してるのかみたいな話をしたらいいかなと思って持ってきました。
03:02
ちなみにこれはたかぴーは書いたことありましたっけ?
私はそうですね、レポートについては書いてないですね、まだ。
なのでちょっと今後書く機会があればチャレンジしたいみたいなと思います。
確かにそうですね。
これ急に1年前から始めたんですけど、
何でこれ始めたかっていう話からしてみようかなと思うんですが、
ことの始まりはVPOEの柴田さんの方から、
そういうGitHubとかAWSとか、そこからのプラットフォームサービスっていうのは、
何かしらそういった障害レポートみたいなのを公開してるよねっていう話があって、
これをペパボでもやってみたいねっていう話があったんですよね。
どういう文脈からそういう話になったかっていうと、
一つはペパボの中でもサイトリライアビリティエンジニアリング、
SREをやっていこうっていう流れができてきた頃に、
SREやるんだとしたらそれによってきちんと可用性が高まってるとか、
開発効率が良くなってるっていうことを外にアウトプットしていきたいねっていう文脈の一つの方法として、
こういった可用性レポートみたいなのどうですかっていうのが話としてあったのが最初ですね。
はい。
当時って、カラーミショップってもう十数年やってるサービスなので、
いろんな評判があったんですよね。
いい評判もあればちょっと重いとか遅いとか、いろんなネガティブな評判も含めていろんな評判があったんですけど、
そういうのって結構印象が強く残る瞬間とかがあったときに、
それがずっと本当は改善してたり場合によっては悪くなってるんだけど、
その時の一時的な印象でずっと続いていってしまうみたいなことはたびたび自分たち自身もあるよなと思ってて、
実際カラーミショップどうなんですかっていうのをきちんとファクトを示して世に説明したいという意図もあったっていう感じですね。
ソーシャルのモニタリングとか私たちももちろんしてるんですけど、
そういう中でも結構重いとか遅いとかっていう声が無視できないぐらいの数はあったので、
そういったところに対してファクトとしてはこうだよとか、
あるいは落ちるみたいな話があった時に実際どれぐらい落ちてるのかとか、
その落ちたことに対してどういう対策をしてるのかみたいなのをオープンにしてやっていくことは、
マイナスな面はないよなと思ったので、
そういったところから始まってたっていう感じですね。
そうですね、はい。
とはいえ何もしてないのに、
こうでしたとかこれだけ障害が起きてましたって出すだけではあんまり意味がないので、
06:02
最初の1回目を出す前ですね、
その前四半期ぐらいに可用性向上プロジェクトっていうのを大々的に社内で体制を組んでやったんですよね。
これは確かたかぴーも入ってくれてますよね。
そうですね、私のチームでそちらを実施してましたね、はい。
なのでそういった取り組みをまずやってみて、
その結果こういうふうに良くなったよとか、
それをやってもここはまだ改善ポイントなのでこれから取り組んでいきますみたいなのを出してみよう
っていうのが一番最初でしたね。
そうですね。
実際あの時はどういうメトリクスを見たかって覚えてます?
そうですね、一通りダッシュボードを作って見ていったんですけど、
いろいろネットワーク周りだったりとか改善すべきポイントはあったんですけど、
一番ボトルネックとなってたのがスロークエリの問題で、
それを中心に見ていった記憶がありますね。
一番外側のメトリクスとしては確かショップページですよね。
そうですね。
私たちが提供しているショップさんのショップのトップページだったり、
商品ページだったりのレスポンスタイムですかね。
そうですね、レスポンスタイムを計測してましたね。
それを分析していくと時間がかかっている要因は主にはスロークエリというか、
MySQLのクエリが一部重いものがあったり、
意図しないようなクエリが投げられてしまうようなケースがあって、
それがどうも、その時は95%タイルか99%タイル確か見てたと思うんですけど、
それの悪化の原因になってたっていうのが分かってきたので、
それをバシバシ倒していくみたいなのをやってたんですよね。
そうですね。
それで結構いい効果が出たというか、
かなりあれでレスポンスタイム改善したので、
これはちゃんと出しましょうっていうのもあって、
うまくいったからレポートにしたっていうのも半分ぐらいはあります。
そのおかげで結構いいというか、
これだけ良くなったし、これだけまだ問題点は私たちの中でも把握できているので、
やっていきますっていうのがある程度形になって出せたかなとは思いますね。
そうですね。
こういう障害とかセキュリティーインシデントとかって、
もちろん起こらないのが一番いいんですけど、
これゼロにできるかっていうと現実的にはかなり難しいというか、
不可能に近いと思うので、
それをどうやって減らしていくかとか、
妥当なコストできちんと高い可用性だったり、
セキュリティーを担保していくかっていうのは、
技術的にはかなり面白いというかチャレンジが多い分野ですよね。
そうですね。
09:00
だからそういうところで、
こういう障害が起きてしまいましたとか、
こういう理由で起きてしまいました。
で、それに対して現実的に打てる手はこれなのでこれをやっていきますとか、
それによって同じ障害はもう起きないように、
私たちの中では対策をしましたっていうのをちゃんと見せていくっていうのは一つ。
これからいろんな、
これからというか今もいろんなサービスをやっている企業さんだとか、
プラットフォームをやっている会社さんは当然のようにやっているので、
それに私たちもちゃんと習っていきたいねというのはありましたね。
そうですね。
で、これに関しては、
さっきタカピはまだ書いてないよっていう話してましたけど、
どういう体制でこのレポートを、
市販機に1回なんですけど書いてるかっていうのをもう少し話していこうかなと思うんで、
ちなみにその書くプロセスみたいなのはタカピは知ってますか?
書くプロセスというのは、
なんかどういうふうに書かれているか?
レポート自体の書き方みたいな感じですかね。
はいはいはい。
そのなんていうんですかね、大間から流れについては、
例文みたいなのがあるんですかね。
なんかそれにのっとって書いてるような感じは。
はいはい。
しましたがどうなんでしょう?
そうですね、たぶんこれも今の執筆体制というか、
記事を作る体制っていうのが、
1年やって4回はできてるんですけど、
まだ4回っていうのはあるので、
まだまだこなれてないところもあるんですけど、
最初1回目のやつは私が全部書いたんですよね。
下書きと図を書いて、
外部に公開するものなので、
お知らせですかね、
当時はヨムヨムカラーミーっていうメディアに確か出したんですけど、
外部にカラーミーショップの公式のお知らせとして出すので、
それのレビュープロセスがあるので、
それのレビューをお願いしたり、
あとは私が適当に書いた図だったので、
それをデザイナーさんに聖書していただいたりとか、
そういうのを経て5目は出したんですけど、
2つ目の記事からは、
私じゃない人に書いてほしいなと思ったので、
次の人を指名する形でどんどん回してもらおうという感じで、
今回はこういうふうにして書いたので、
次あなた書いてくださいっていうのを、
今当番というか指名制で回してもらってますね。
可要性レポートの書き方みたいなノーションのページを1個作っていて、
それを最初自分がこうやって書いたよっていうのを書いていたんですけど、
次々と次に書く人が、
今回はこうしましたとか、
こういうふうに改善しましたっていうのをアップデートしてくれてるので、
それを見ながらどういうプロセスで、
誰にいつ何をお願いしたらいいかみたいなのが全部書いてあるので、
それに沿って文章を書いてもらうみたいな感じになってますね。
なるほど、ノーションにまとまっているんですね。
ですです。
これは結構4回続いていいノウハウがたまってるので、
12:03
書く内容に関しては、
だいたいこういうフォーマットというか、
流れで書いたらいいよっていうのはだいたいあって、
この市販機でこういうことがありましたっていうのを書いて、
それに対してどういう手を打ちましたとか、
これからどういう手を打つつもりですっていうのを書くっていうのが一般的なテンプレー。
前回はこういう話をしたんだけど、
今回はそれがやっぱりダメだったんでこういう方法しましたとか、
前回はこれをやるって言ってたんですけど、
それの進捗はこうですみたいなのを最後に書いたりしてもいいみたいな感じで、
今書いてもらってますかね。
なるほど。
今日はそうですね、その文言みたいなところだと、
いわゆる技術文章ではあるんですけど、
読むのはショップオーナーの方だったり、
あるいはその私たちのお客さんのショップを、
例えばデザインしてる方だったりとか、
お手伝いしてくださってるような方とかが見るので、
難しすぎる用語を使えないんですよね。
例えば、それこそSLIとかSLOとか言ってもどうしようもないんですよね。
あとはそうですね、レスポンスタイムとかも難しくて、
もうちょっとわかりやすい表現にしなきゃいけないねとか、
そういうところは絡みショップのお知らせの書き方の、
用語集じゃないですけど、こういう表現をしましょうとか、
こういう時はこういう言い方をしましょうっていうのが、
一応それもリストが、リストというかディレクターの皆さんの中で、
ルールというかが共有されてるので、
そういう観点でレビューしてもらえると、
すごい読みやすい文章になったり、
便宜なものになって助かるなというふうには思いますね。
そうですね、レスポンスタイムと言われてもみたいなところがありますからね。
結構サーバーとかも難しくて、
データベースとかもなかなかイメージしづらかったりするんですよね。
そうですね、構成がわかってないとどうやってデータを取得してるのかすら、
やっぱり一般の人はイメージできてないと思うので、
そこら辺の書き方とかは確かに難しそうですね。
今見たらレスポンスタイムはショップページの表示にかかる平均時間みたいな感じになってましたね。
いいですね、確かに。
わかりやすい。
そんな感じで可用性レポートというか、
私たちは安定したサービス提供のための改善レポートという名前でやってるんですけれども、
そういう取り組みをかれこれ1年ぐらい無事続けられましたよっていうのが、
今日のトピックですかね。
継続的にやっていきたいですね。
そうですね。
なのでもうすぐ第三四半期、三級が9月に終わったらたぶん10月とか11月とかに
15:01
誰かが書いて出すことになるかなとは思うので、
また楽しみですね。
そうですね。
じゃあ今日はそんなところなんですけど、
他に何かこれについてとかあるいはおまけで話したいこととか何かありますか?
そうですね、何かあるかな。
特に可用性については話してきたのかなとは思っているので、
じゃあ締めましょうか。
それでは今回はここまでとします。
ひとなみクラブのご意見ご感想は、
ツイッターのハッシュタグ、
ひとなみクラブか、
ひとなみクラブのツイッターアカウント、
h173にあるマシュマロを投げるのリンクからいただけると嬉しいです。
では皆さんご視聴ありがとうございました。
ご視聴ありがとうございました。
15:58

コメント

スクロール