Cybozu Inside Out | サイボウズエンジニアのブログ

 

サイボウズ Live アクセス障害の裏で起こっていたこと

どうも!アプリケーション基盤チームの@yokotaso です。

2017/11/13 にサイボウズLiveの長時間にわたる障害が発生しご迷惑をおかけしました。

技術的な調査が一段落し、対応を進めております。

障害にいたった原因と対応のお話をさせていただきます。

簡単なまとめ

  • Java8u152以降で、CPU負荷が高まる現象
  • Java標準のデシリアライズとSecurity Managerの相性が悪くなった
  • 解決策は現時点では存在しない。サイボウズLiveでは、Java標準のデシリアライズをやめる準備段階

障害発生時の状況

障害発生の数時間前に、運用マシンのメンテナンスを行っておりました。

  • Javaのマイナーアップデート
  • カーネルのアップデート
  • その他、設定ファイルなどの更新

障害発生時には次のような現象が見られました。

  • JavaプロセスがCPU高負荷状態
  • MySQLに大量のロック及びエラーが発生

監視システムが警告した時にはこのような状態になっており、問題の切り分けが難しい状態でした。

時系列の対応はブログの最後に書いておきますので、興味のある方はどうぞ。

最終的にJDKをダウングレードし、障害が収束しました。

原因の特定

メトリクスやChange logから考えられる原因は無数に存在しました。

  • Full GCでThreadがHungした説
  • MySQLの大量ロックが発生していたので、JDBCドライバとJDKの相性が悪い説
  • 機材故障説
  • DoS攻撃説

などが考えられましたが、どれも根拠に乏しく断定ができませんでした。

調査の結果、slow.logから数万件のオブジェクトをWebサーバーで生成していることがわかりました。 同様の現象が発生するデータで検証したところ、5~8倍程度のパフォーマンスの劣化が判明しました。

検証環境で perf コマンドを利用した結果です。

プロファイル例: perf record -a -p <PID> sleep 20

Java8u152

$ sudo perf report
# (省略)
# Overhead  Command  Shared Object       Symbol 
# ........  .......  ..................  .....
#
    15.64%  java     libjvm.so           [.] JVM_GetStackAccessControlContext    
     7.70%  java     libjvm.so           [.] Method::validate_bci_from_bcx  
     7.57%  java     libjvm.so           [.] vframeStreamCommon::next  
     6.71%  java     libjvm.so           [.] java_lang_Class::protection_domain
(省略)

Java8u144

$ sudo perf report 
# (省略)
# Overhead  Command  Shared Object       Symbol 
# ........  .......  ..................  .....
#
     3.11%  java     libjvm.so           [.] InstanceKlass::oop_oop_iterate_nv   
     2.90%  java     perf-8026.map       [.] 0x00007f953268275b   
     2.06%  java     perf-8026.map       [.] 0x00007f9532678c5d
(省略)         

0x...で始まるものはJITコンパイルされたコードです。

JVM_GetStackAccessControlContext はSecurityManager関連のメソッドです。SecurityManagerが怪しい。

この結果を元に障害発生時の ThreadDumpを読んでいきます。次の部分で停止しているThreadが大量にありました。

"http-bio-8080-exec-24" #64 daemon prio=5 os_prio=0 tid=0x00007fe984007000 nid=0x3352 runnable [0x00007fe9d9283000]
   java.lang.Thread.State: RUNNABLE
 at java.security.AccessController.getStackAccessControlContext(Native Method)
 at java.security.AccessController.getContext(AccessController.java:820)
 at java.io.ObjectStreamClass.newInstance(ObjectStreamClass.java:1093)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2048)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2282)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2206)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2064)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
 at java.util.ArrayList.readObject(ArrayList.java:797)
 at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2173)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2064)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1568)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:428)
 ....(以下プロダクトコードが続く)

この検証からJava8u152でSecurity ManagerをOFFにしたところ、パフォーマンス劣化現象が発生しなくなったため、Security Managerが原因の可能性が高いと判断しました。

Java Security Manager でセキュアなサービスを構築しよう でも言及されているように SecurityManagerはパフォーマンス対策が行われていました。原因の可能性が低いと判断していたため、初期の段階で原因として排除してしまいました。

JDKの原因

OpenJDKの改修は次のとおりです。 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/58243fea3fe2#l1.152

調査の結果、次のようなことがわかりました。

  • Java標準のクラス以外をデシリアライズするときに、 java.security.AccessController.getStackAccessControlContext が実行される
  • java.util.List をデシリアライズすると、Listのサイズと同じ回数のjava.security.AccessController.getStackAccessControlContext が実行される
  • java.security.AccessController.getStackAccessControlContext は計算コストが高い

サイボウズLiveでの原因

サイボウズLiveではクエリの結果をキャッシュする機構で、シリアライズ/デシリアライズ用いてオブジェクトのディープコピーを行っていました。 キャッシュするクエリの結果が大きいときに、今回の現象が発生していました。

障害のシナリオは次のように考えています。

  1. 大量のキャッシュ生成が発生するリクエストが実行される
  2. (1)のトランザクション内でテーブルロックするクエリが実行される
  3. (1)のトランザクションが終わらない
  4. 滞留したリクエストが原因で最終的にMySQL側でロックが報告される

データ量や実行されたリクエストに依存して発生する現象だったため、発見に時間がかかってしまいました。

java.security.AccessController.getStackAccessControlContext が数万回実行されてしまうケースがあったと思われます。

アプリケーションサーバーが非常に高負荷だった状況とも整合性がとれます。

サイボウズLiveでの対策

前述ですが、Security Managerのパフォーマンスを改善するために独自のSecurityManagerクラスを実装しています。 これによって、計算コストが高いメソッドがコールされることを回避しています。

JDKの改修では計算コストが高いメソッドがハードコードされているので、 Security Manager を利用するのであれば解決策は、Java標準のシリアライズ/デシリアライズをやめることです。

サイボウズLiveとしては、次のような対策をとる予定です。

  1. データベースの結果キャッシュは、シリアライズ/デシリアライズの処理をkryoライブラリに置き換える
  2. (1)をリリースして問題ないことを確認した後 JDKを再度アップデート

参考: github.com/EsotericSoftware/kryo

JDKの脆弱性に該当しないのか?

サイボウズLiveのJDKのアップデート直後に、CPU負荷が高まりアクセスしにくい状況になりました。 JDKのアップデートの結果、今まで処理できていたリクエストがDoS攻撃になってしまいました。

このことからJDKの脆弱性の可能性もあるとして、Oracleに脆弱性報告させていただきました。 Oracleからは脆弱性には当たらないと回答を得られました。その回答をもって、ブログで公開しています。

CPU負荷が増加傾向にある方は一度ご確認ください!

他のプロダクトの影響は?

Security Manager、Javaの標準のデシリアライズ 機能 を利用していると発生する可能性があるということで、他のプロダクトへの影響も調査しました。

kintoneでは、デシリアライズ を使っていましたが、Javaの標準クラスのみでした。

f:id:cybozuinsideout:20171212181034p:plain

Javaの標準クラス以外がデシリアライズされる可能性を調査したところ、3行の型変換のおかげで障害を回避していたことがわかりました。 はるか昔にコミットされた3行に圧倒的...感謝…!

教訓

うまくいったこと

  • 原因の切り分けが難しいときは、断片的な情報からしらみつぶしで原因究明にあたること
  • バイアスにとらわれている可能性も頭の片隅に入れること
  • 障害発生時のメトリクス情報から、プロファイリングツールを適切に使いこなす大切さ

うまくいかなかったこと

  • サイボウズLiveには運用環境をプロファイリングできていない。問題の切り分けに時間がかかった
  • リリース前の性能評価がうまくできていない
  • 夜間など稼働率が低い時間帯のアップデートは問題の早期発見を難しくさせると学んだ
  • カナリア・リリースが我々には必要

参考: カナリアのおかげで命拾い : CRE が現場で学んだこと

最後に

サイボウズLiveを安全にご利用いただくためのアップデートが、障害を起こしてしまい大変ご迷惑をおかけしました。

2017/12/19 の障害は今回の障害を踏まえたJDKアップデートの布石のための修正が原因でした。度々のアクセス障害、大変申し訳なく思っております。 決して手を抜いているわけではないです。そこだけはどうか、ご理解いただけると幸いです。

2019年に終了してしまうプロダクトではありますが、出来る限り安全にご利用いただけるよう手を尽くしていきますので、よろしくお願いしたします。

2016年の懺悔に引き続き2017も懺悔したので、来年は良い年になりますように。

来年も引き続き、技術ブログをお楽しみいただければと思います。では、良いお年を!

障害の時系列対応

時間 対応
08:06 JST モニタリングシステムより通常警告を受信。JVM threads 数に上昇傾向があることを視認。
08:22 JST モニタリングシステムより緊急警告を受信。詳細な調査を開始。
08:35 JST ログイン画面は表示されるがログインができない状態。アクセスログを調査しても正常時と比べて大きな変化は確認できない状況。
09:22 JST 切り分けのため、Javaアプリケーションサーバの再起動を実施。
09:38 JST Javaアプリケーションサーバの再起動後、ログインはできたが非常にアクセスが重い状態。
10:16 JST データベースサーバの不具合を疑いスレッドダンプを取得し調査。応答待ちが多い状況を確認。
11:31 JST 特定のUPDATE クエリが顕著に遅いことを確認。クエリに問題は見受けられないなため、物理機材を疑い HDD や SSD の状態を調査。
11:41 JST データベースサーバの SSD に不具合の傾向を確認。当該 SDD の切り離しを実施。
11:48 JST await は改善したが、未だサイボウズ Live のアクセス状況は改善せず。
12:03 JST クライアントコネクションに起因する問題を疑い、1つのデータベースサーバにて全 MySQL コネクションの kill を実施。結果、効果が認められず。データベースサーバ自体の問題を疑い、スイッチオーバーを試行。
12:06 JST スイッチオーバーの実施後もアクセス状況に改善は見られず。
12:09 JST 再度、Javaアプリケーションサーバの再起動を実施するが、JVM threads 数が即上昇。
12:17 JST ~ 14:42 JST スイッチオーバーを実施した際に Master, Slave 間で一部データ不整合が発生したため、この対応を実施し、復旧を確認。
改めて障害の切り分け対応を議論し同時アクセス数を絞って原因箇所を探ることを決断
16:15 JST 社外からの同時アクセス数を 10 に制限。改善見られず。
16:43 JST 社外からの同時アクセス数を 1 に制限。改善を確認。
16:53 JST 社外からの同時アクセス数を 2 に変更。少し遅くなることを確認。
16:59 JST 社外からの同時アクセス数を 4 に変更。明らかに遅くなる状況。次の試行策として、11/12(日)にアップグレードした JDK のダウングレードを決断。
17:42 JST JDK のダウングレードおよび仮想アプリケーションサーバの再起動を実施。改善を確認。
17:47 JST 社外からの同時アクセス数を 10 に変更。
17:53 JST 社外からの同時アクセス数を 20 に変更。
17:58 JST 社外からの同時アクセス数を 40 に変更。
18:01 JST 社外からの同時アクセス数を 80 に変更。
18:08 JST 社外からの同時アクセス数を初期設定に戻す。ここで全体のアクセス状況の復旧を確認。
18:24 JST スタックダンプを取得し、その他関連する仮想サーバの再起動を実施し完全復旧を確認。
 

スプリングインターンシップ2018を開催します!

こんにちは!品質保証部の中園です。

2018年2月、サイボウズでは初のエンジニア&デザイナー向けスプリングインターンシップを開催することになりました!

f:id:cybozuinsideout:20171221101122p:plain

今回は4つのコースをご用意しました。

スプリングインターンを通して、サイボウズのことをより知っていただけると嬉しいです。

(2月ですが、)サイボウズで熱い熱い5日間を過ごしましょう!

皆さんのエントリーをお待ちしています!

募集要項

日時

2018年2月19日(月)~23日(金)

場所

東京オフィス

就業時間

9:00~18:00

※ 初日は10時集合、最終日は懇親会を実施するため20時~21時頃解散となります

対象

2019年4月の入社が可能な学生

募集人数

各コース1回につき3名程度

選考

書類選考、面接(Webも可)1回

待遇

日給8,000円

※ 遠方からご参加いただく方には、交通費・宿泊費を支給します

エントリー方法

こちらよりエントリーしてください

お問い合わせ

  • 人事部: 本林 明子
  • メールアドレス: recruit_contact@cybozu.co.jp
  • 電話番号: 03-4306-0870

Webサービス開発コース

Webサービス開発コース

概要

サイボウズが提供するkintoneの機能のプロトタイプを作成します。

テーマは実際のユーザーや社内での要望を元に、仕様検討や実装、テストの自動化にチャレンジしてもらいます。

インターン期間中はkintoneを開発する社員がメンターとして指導やコードレビューを担当し、大規模なWebサービス開発の現場を体験することができます。

必要な経験/スキル

  • Webサービス開発の経験
  • JavaもしくはJavaScriptの知識

あると望ましい経験/スキル

  • Git/GitHubの使用経験

モバイルアプリ開発コース

モバイルアプリ開発コース

概要

サイボウズのモバイル製品に簡単な機能を実装していただきます。

製品のソースコードに触れたり、テスト・コードレビューを通じて実際の開発現場を体験することができます。

必要な経験/スキル

  • iOS(Swift) の開発経験

あると望ましい経験/スキル

  • Git/GitHubの使用経験

UX/UIデザイナーコース

UX/UIデザイナーコース

概要

サイボウズのデザイングループメンバーとともに、製品・サービスのデザイン業務に取り組んでいただきます。

自由な発想を活かして新しいデザインを提案してください。

必要な経験/スキル

  • PCやスマホ向けのデザイン経験
  • ポートフォリオ

あると望ましい経験/スキル

  • ユーザーリサーチの興味、経験
  • プロトタイピングスキル
  • チャレンジ精神

品質保証コース

品質保証コース

概要

サイボウズ製品のテスト業務を通して、サイボウズ製品の品質がどのように担保されているのか、品質とは何なのかを体験していただきます。

実施内容としては、以下を予定しています。

  • サイボウズ製品のテスト設計、テスト実施
  • Seleniumを使った簡単な自動テストの作成

現役の品質保証部のメンバーがメンターとなり、手厚くサポートをしますので、テスト自動化やテスト未経験の方でも大歓迎です。

必要な経験/スキル

  • ITに関する基本的な知識がある
  • Webサービスのテストについて興味がある
  • 「品質保証」という概念を説明できる
  • 地道な作業をコツコツとすることが好きである

あると望ましい経験/スキル

  • Webサービスのテスト経験
  • プログラミング経験(言語問わない)

2017年サマーインターンの開催記事

 

Cybozu Tech Conference 2017 開催報告

こんにちは。コネクト支援チームの成田です。

12/2(土)に、サイボウズが主催するイベント「Cybozu Tech Conference 2017」を開催しました。

f:id:cybozuinsideout:20171213111916p:plain

Cybozu Tech Conference について

「Cybozu Tech Conference」は、サイボウズが主催する、techな人向けのカンファレンスです。 サイボウズが、チームのためのクラウドサービス「cybozu.com」を開発、運用する中で、日々蓄積された学びを多くの方々と共有し、そのフィードバックから私たちも学びたいという思いで、昨年からスタートしました。

昨年は様々な技術トピックを紹介してきたのですが、今年は、エンジニアを取り巻く環境に焦点を当てたテーマのパネルディスカッションや発表が行われました。

発表

パネルディスカッション以外の発表資料はすべて公開しておりますのでぜひご覧ください。


開発文化を育て、広げる愉しみ - 海外拠点Kanban導入記 -

当日の Twitter のつぶやきは、togetter でまとめています。
https://togetter.com/li/1178341

懇親会

ピザやお寿司、スイーツなどをいただきつつ、サイボウズ社員と参加者で親睦を深めることができました。懇親会中に開催したLT大会では、サイボウズの社員だけでなく社外の方々にも発表していただき盛り上がりました。 LTで発表していただいた皆さま、ありがとうございました!!

f:id:cybozuinsideout:20171213113608p:plain

おわりに

去年からテーマを大きく変えたこともあり、どれだけの方に興味を持っていただけるか不安もあったのですが、 結果、去年より多くの人にご来場いただけました。懇親会やLTでも盛り上がることができよかったです。

これからもサイボウズの技術情報や働き方など、技術発信のためにイベントを開催していきたいと思っています。 興味ある方は、connpassグループ「Cybozu Inside Out」をチェックしてください!

ご参加頂いた皆さま、ありがとうございました。今後ともよろしくお願いします!

 

開発文化を育て広げる愉しみ

どうも!アプリケーション基盤チームの@yokotaso です。

先日のCybozuTechConference 2017で、「開発文化を育て広げる愉しみ」という内容で登壇させていただきました。 発表内容のカンペを公開します。

かわゆいまとめをしていただいたので、お忙しい方はこちらをどうぞ!

f:id:cybozuinsideout:20171205122410j:plain

文章にはなってしまいますが、どうぞ!

f:id:cybozuinsideout:20171205123010j:plain

「開発文化を育て広げる楽しみ」という話をさせていただきます。今日は宜しくお願いします。

2011年にサイボウズ新卒入社の横田と申します。Webアプリケーションエンジニアとして主に働いております。

本題の前に

f:id:cybozuinsideout:20171205123016j:plain

本題に入る前にすこしお話しさせてください。

まずはチーム開発開発体制について。 ユーザー管理などの管理機能の開発を行なっています。 日本で開発と上海で試験の2拠点体制です。

開発のScrum化の波に乗りまして、我々もScrumを採用しています。 Scrum 開始当初は、1 Sprint内で開発から試験設計までを完了がDoneの定義になっていました。 最近はすべてのタスクというわけではないですが、 1 Sprintで開発から試験完了まで1個流しができるようになってきています。

f:id:cybozuinsideout:20171205123018j:plain

なぜKanbanを採用したのかですが、マルチプロジェクト担当メンバーが多い問題がありました。 影の仕事の存在があったり、誰が何をやっているのかわからない問題がありました。

加えて、開発から試験完了までの仕事はどんどん高速化していきたいので、 上海と日本で多拠点でKanbanをやってみようということになりました。

開発文化の歴史

f:id:cybozuinsideout:20171205123021j:plain

次に、開発文化の歴史についてお話させて下さい

f:id:cybozuinsideout:20171205123024j:plain

サイボウズはもともとオンプレミス・ビジネス中心でした。年単位で開発・試験スケジュールが組まれていました。

ユニットテストがないプロダクトや開発Fixが近くなると動き出す名ばかりのデイリービルドなど悪しき慣習がありました。

開発文化らしいものはなかったんじゃないかと思っています

f:id:cybozuinsideout:20171205123027j:plain

そこからクラウド・ビジネスに挑戦しはじめるわけですが、 前のスライドから開発効率が悪いというのはお察しいただけると思います。

あっという間に緊急リリースが乱発しまして、 品質の不安定化と開発工数の爆発に悩まされることになります。

こういった実務的な問題を解決するために、継続的インテグレーション・継続的デリバリーを利用するようになります。 今まではプロダクト開発をメインに投資を行ってきましたが、開発効率向上のために積極投資をするようになります。

f:id:cybozuinsideout:20171205123029j:plain

ビジネスの主軸がオンプレミスからクラウドの移ろいと時を同じくして開発文化も変化していきます。

クラウド創世記の開発文化をベースに改善を続けてきました。 その結果、開発効率が向上したので開発のボトルネックが少なくなってきました。

そこで、開発から少し視点をあげてリリースまでのプロセス全体の改善したい欲がでてきました。 開発から試験工程までを含めて全体最適化をしていくために、Scrum/Kanban型の開発スタイルへ移行していきます。

開発効率向上のための仕組みから、価値を素早く届けるための開発文化に進化してきます。

f:id:cybozuinsideout:20171205123032j:plain

開発文化は、サイボウズのビジネスを支える重要なファクターに位置付けられるようになってきています。

疑問

f:id:cybozuinsideout:20171205123034j:plain

開発文化の歴史を話してきましたが、社会人経験がある人は、疑問を持ってるかもしれません。

f:id:cybozuinsideout:20171205123038j:plain

クールにみえる開発文化がなんでうちには馴染まないんだろう?とか

f:id:cybozuinsideout:20171205123040j:plain

開発のベストプラクティスと呼ばれるものを導入したけど、廃れちゃったとか

f:id:cybozuinsideout:20171205123043j:plain

そんなのサイボウズだからうまくいくんだろうとか

f:id:cybozuinsideout:20171205123046j:plain

ただ、これってサイボウズでもよくある話なんです。

失敗から改善したり、少しづつですが前に進み続けて今の開発文化があります。

f:id:cybozuinsideout:20171205152223j:plain

開発文化を定着させるためのコツがあるっぽいので、

日本と上海のKanban導入と過去の失敗をネタに

開発文化を育てるためのプラクティス

f:id:cybozuinsideout:20171205123048j:plain

開発文化を育てるためのプラクティスについてお話ししようと思います。

ボトルネックは文化の母

f:id:cybozuinsideout:20171205123108j:plain

さて、一つめですが、ボトルネックは文化の母です。

f:id:cybozuinsideout:20171205123111j:plain

開発プラクティスは開発プロセスのボトルネックを解消するでしょうか? 無理に作ったり導入した開発文化というのはうまくいきません。 導入したら、どうボトルネックが解消されるのか?を考えましょう。

逆にボトルネックが解消されない文化は廃れがちです。 コードやチームの状況を見極めた上で、必要な開発文化を作っていく必要があります。

f:id:cybozuinsideout:20171205123114j:plain

過去の失敗例です。UnitTestを広めようとして失敗したことがあります。 UnitTestが当たり前の開発体制にしたかったんですが、見事に失敗しました。 今思い返すと、当時はまだチームの開発文化として取り組むのは早かったと反省しています。

UnitTestのあるなしは大きなボトルネックではなかったのです。他にもっと大きなボトルネックがあったのでした。

f:id:cybozuinsideout:20171205123117j:plain

その大きなボトルネックは、クラウドとオンプレミスのアーカイブが同時にビルドされないことから生じる問題でした。 そこで、オンプレ・クラウドのデイリービルドを自動化しました。

オンプレミスとクラウドのアーカイブを毎日好きな時間に作れるように刷新しました。 オンプレ・クラウドの同時試験が可能になりました。 試験が同時にできないのが実は大きなボトルネックだったのです。 こういうボトルネックが解消されて初めてオンプレミス・クラウドの環境を意識した開発を行うことができるようになるのです。

f:id:cybozuinsideout:20171205123120j:plain

これだけだと開発文化も何もないんですが、これが新しい開発文化のベースになったりしていくわけです。 開発プロセスのボトルネックから導入する開発プラクティスを見極めていきましょう。

仲間を増やそう

f:id:cybozuinsideout:20171205123124j:plain

次は「仲間を増やそう」です。

f:id:cybozuinsideout:20171205123127j:plain

サイボウズで開発文化として定着したものを振り返ると全員参加型の勉強会を開いていることがとても多いです。

目的は、

  • 知識のベースラインを揃える。
  • 共通の語彙と知識をつける。
  • 問題意識の共有をする。

です。

勉強会のコツですが、シンプルな原理・原則を理解を理解してもらうことが大事です。 そして、全員参加しやすい勉強会にしていきましょう。勉強会の目標をシンプルにして、妥協できるところは妥協していきましょう。

f:id:cybozuinsideout:20171205123130j:plain

Kanbanを導入した時の話ですが、日本・上海で合同の勉強会を開きました。

カンバンの理解としては、WIP(Work In Progress/進行中の仕事)や仕事の流量制限がなぜ大事か?仕事の可視化について、重点的に勉強しました。

f:id:cybozuinsideout:20171205123133j:plain

輪読に利用したカンバン仕事術は、日本語版と中国語版が出版されているので、こちらを利用しました。 言葉は、本質的ではないので使えるものは使いました。

f:id:cybozuinsideout:20171205123135j:plain

また、カンバン仕事術特有ではあるのですが付録にゲームが付いているので、毎回の勉強会の最後にゲームを実施しました。 ゲームを通して、Kanbanの原理原則を体感してもらいました。

なぜ、重要なのか?を共有するのは、開発文化を作っていく上で、重要です。

f:id:cybozuinsideout:20171205123138j:plain

逆に失敗してしまった例ですが、有識者で勉強会を開いてしまったことです。 開発文化にしていきたかったのに、特定メンバーのみで勉強会を開いてしまったことです。

メンバー全員と問題意識の共有ができないだけでなく、メンバー間で知識差ができてしまう原因にもなりました。

小さく始めよう

f:id:cybozuinsideout:20171205123141j:plain

次はSmall Start、読んで字のごとく「小さく始める」という話です。

f:id:cybozuinsideout:20171205123143j:plain

とにかく小さく、早く始めていきましょう。

1週間、1つみんなで決めた簡単なプラクティスに取り組んでみるくらいから始めてみましょう。 無理をしてすべてを取り入れる必要はありません。

f:id:cybozuinsideout:20171205123146j:plain

うまくいったパターンでは、すぐにKanbanを始めました。 できるだけシンプル、簡単なKanbanを作ってみました。上海拠点も自分たちのカンバンを作ってもらいました。 自分たちのKanbanを作りながら勉強会を進めることで、勉強会のネタに合わせてKanbanを改造したり試行錯誤できるわけです。

やっていくうちに、改善アイデアを思いついたりや新たな気づきなどもあります。 改造することを前提に簡単に始めるのがおすすめです

f:id:cybozuinsideout:20171205123149j:plain

失敗例として、知識を一通り身につけてから実践しよう としたことがあります。 ひとまず一通り知識を身につけてから開発プロセスに組み込もうとしました。

ベストプラクティスを謳っているにもかかわらず開発プロセスにそのまま組み込めないものは多いです。 その現実に疲れてしまって、本質的な開発プロセスの改善に時間を使えず、失敗しました。

開発プロセスや組織の状態を考慮して、プラクティスの改造、取捨選択が必要なのです。

効果的な振り返りをしよう

f:id:cybozuinsideout:20171205123153j:plain

小さくはじめたら、いいタイミングで振り返りをしましょう。

f:id:cybozuinsideout:20171205123156j:plain

開発文化を定着させてるために効果的な振り返りをしましょう。開発プラクティスの原理・原則を意識して、振り返ります。

振り返り内容に、開発プラクティスの原理原則を意識した内容がでてくればメンバーに知識が定着しているだけでなく、 日々それを意識して仕事にあたってくれているのがよくわかります。

例を見てみましょう

f:id:cybozuinsideout:20171205123159j:plain

これは、我々のチームででてきた実際の振り返りの内容です。 原理・原則を意識してチームの問題を解決することができた例です。

褒めるポイントが明確で、どう解決したのか?の考え方がよくわかりますね。 チーム全体の処理中の仕事の量を意識して仕事ができるようになっているのがわかります。

f:id:cybozuinsideout:20171205123204j:plain

今度はProblemを見てみましょう。

根拠が明確になり、kanban導入以前では見えていなかった開発プロセスの問題が出てきているのが分かると思います。

普通に開発していたら、WIPが多いとか気にしないですよね。 チームメンバーにKanbanの知識が定着して、それを使って考えることができている証拠ですね。

f:id:cybozuinsideout:20171205123206j:plain

よくないパターンですが、ふんわりした振り返りをしてしまう。

根拠が明確でない・瑣末なProblemをとりあげて、複雑な回避策を採用していませんか? 開発プロセスのボトルネックを解消できるProblemの発見、調査、解決に注力しましょう

KAIZENと守破離

f:id:cybozuinsideout:20171205123211j:plain

振り返りを終えたらKAIZENです。

f:id:cybozuinsideout:20171205123214j:plain

一般的なプラクティスをただ適用するのではなく、 それぞれのカルチャーに合わせて取捨選択して改造してきましょう。

なぜ、改造や取捨選択が大切なのかはあとでお話しします

f:id:cybozuinsideout:20171205123217j:plain

たとえば、こういう Problemがあって、Kanbanを観察した結果、KAIZENするべき内容をきめたとします。 ちょっとわかりにくいと思うので、簡単なKanbanの図で説明します

f:id:cybozuinsideout:20171205123219j:plain

f:id:cybozuinsideout:20171205123222j:plain

f:id:cybozuinsideout:20171205123225j:plain f:id:cybozuinsideout:20171205123229j:plain

プロジェクト開始直後はDoingのタスクはすくないですが、 レビューのフェーズに入ると途端にWIPが高まるのが分かると思います。

f:id:cybozuinsideout:20171205123232j:plain

WIPが高い状態はKanbanでは避けるべき状態です。

f:id:cybozuinsideout:20171205123235j:plain

f:id:cybozuinsideout:20171205123238j:plain

これを改善するためにまず、アバターを導入しました。 そして、Review列を新設して、Reviewには関係者全員を配置します。

f:id:cybozuinsideout:20171205123242j:plain

この改善のおかげでDoingに仕事が持ち込まれないだけでなく、 Reviewはアバターを2人で消費してしまうので、できるだけ早く終わらせたいプレッシャーになるのがお分かりいただけますか?

我々のチームのKanbanを改善例でした。

f:id:cybozuinsideout:20171205123245j:plain

自分たちの状況、カルチャー、問題に合わせてプラクティスを取捨選択・改造して、組織にフィットする開発文化にしていきましょう。 プラクティスを単純に当てはめるのではなく、チームで開発文化を育てていきましょう。

f:id:cybozuinsideout:20171205123248j:plain

海外拠点はどうしたのか?ですが、上海のKanbanも上海のカルチャーを尊重して管理はしていません。

我々とは別のカルチャーや問題を上海も抱えていてそれを解決すべくKanbanを使っています。仕事をしながら日々Kaizenをしてくれています。

私がやったことといえば、最初のKanbanを作るのをお手伝いしたことと、相談や注意喚起くらいです。 勉強会でやることをやった後は、あとは支援するだけです。 ことわざで言うところの魚を与えるのではなく、魚の釣り方を教えるのと同じです。

f:id:cybozuinsideout:20171205123251j:plain

とはいうものの、最終的には日本、上海間で仕事を開発から試験完了まで行いたい目的もあります。

kintoneでタスク処理の基本的なところをやりつつ、各拠点の仕事の流れは各拠点のkanbanで管理しています。

仕事終わりに拠点ごとのKanbanの写真をアップロードしてもらっています。これで多拠点のタスク待ちや他拠点への仕事の依頼のしすぎに気づけるようになっています。

複利と再投資

f:id:cybozuinsideout:20171205123254j:plain

さて、複利と再投資というお話。

f:id:cybozuinsideout:20171205123259j:plain

開発文化として定着したら開発工数が減っていると嬉しいですね。その余剰時間を開発文化に再投資していきましょう。

開発文化を進化させていくのです。新しい挑戦をしていくために開発文化をKAIZENしていきましょう。

f:id:cybozuinsideout:20171205123302j:plain

たとえば、テストエンジニアになるための勉強や今まで煩雑だった試験手順を半自動化するなどに投資できる時間がでてくるわけです。

f:id:cybozuinsideout:20171205123305j:plain

サイボウズは改修後、即リリースというのはまだできていないのですが、実現のためにはさらなる開発文化の進化が必要だと思っています。

f:id:cybozuinsideout:20171205123309j:plain

まだまだやることは盛りだくさんですが、自分たちで開発文化を作り変えてきたことが財産であり、組織と開発体制の基礎体力なのです。

アジャイルな開発プラクティスは実践しなくてもよいが、アジャイルな組織、開発文化を目指していきたいと思っています。

f:id:cybozuinsideout:20171205123312j:plain

必ず何かの問題はあるので、また変わっていきたいと思っております。

まとめ

f:id:cybozuinsideout:20171205123315j:plain

最後は、そして、夢の外へ。

f:id:cybozuinsideout:20171205123319j:plain

サイボウズには拠点・組織をこえて開発文化を育てる取り組みをしてきました。 僭越ながら、開発文化を育て広げるコツをお話ししました。

100組織あったら、100通りの開発文化があって良いと思っています。 なので、自分たちの開発文化がよく知られた開発プラクティスでなくても良いのです。 ベスト・プラクティスと違っててもいいのです。 それよりはボトルネックを解消するための開発文化であってほしいと思います

f:id:cybozuinsideout:20171205123322j:plain

オンプレミス時代から振り返ると隔世の感に驚くばかりなのですが、僕が入社した頃は開発文化がある組織を憧れていました。

頭の中の夢から開発文化のある組織が実現しつつあります。

そして、夢の外へこれからも開発文化を育てていく取り組みを続けたいと思っています。

f:id:cybozuinsideout:20171205123326j:plain

このカンファレンスの大きなテーマに戻ってくるのですが、開発文化を育てることを愉しみたいエンジニアに 少しでも参考にしていただいただければ、幸いです。

f:id:cybozuinsideout:20171205123337j:plain

「開発文化を育て広げる愉しみ」でした。ありがとうございました。

 

「サイボウズ バグハン合宿2017」 開催報告

こんにちは、Cy-PSIRT の大塚です。 

サイボウズでは、3年ぶり2度目となるバグハン合宿を開催 (2017/11/3,4) しました。合宿の様子と結果についてご報告いたします。

バグハン合宿とは?

「サイボウズ バグハンター合宿」、略して「バグハン合宿」。普段オンラインで脆弱性探索をしているハンターの皆様を集めて、寝食を共にしながら脆弱性発見コンテストをやろう!というものです。今回は、15名の方にご参加いただきました。

f:id:cybozuinsideout:20171109143533p:plain

タイムスケジュール

1日目 もくもく 時々 わいわい

決戦の場所は、三浦海岸。遠方の方は前泊して会場入りされていたり、受付時に配ったTシャツをその場で着て臨むという方もいて、スタート前からハンターの皆様の気合いを随所に感じました。途中、チームごとの成果発表やご飯などを挟み、約24時間(1日目 11:00 ~ 2日目 11:00)の戦いがスタートです。 

f:id:cybozuinsideout:20171109171521p:plain

真剣な表情のハンター

今回は、初のチーム戦でした。初めて顔を合わせる方もいましたが、いざ開始すると何かある度に人の輪が出来るチーム、担当製品を分けてもくもくと攻撃するチーム、とそれぞれ特色が出て非常に興味深かったです。チーム戦にしたことで横の繋がりが出来て行くのを肌で感じました。

また、今回は各チームに一人弊社開発者を配置し、ハンターの方々と一緒に脆弱性を探してもらいました。自分たちが作っている製品に対して、攻撃者の視点や手法を屈指し脆弱性を報告される実例を見ることは、今後の開発にとてもプラスとなったようです。

夕食 そして負けられない戦い

宴会場での夕食タイムです。ハンターの皆様もしばし休息の時間...お酒を飲みながらワイワイかなと思いきや、ほとんどの方がウーロン茶を飲んでいました。(翌朝、運営側はその理由を知ることに...。)

f:id:cybozuinsideout:20171109171728p:plain

夕食

そして、夕食もそこそこに始まった「ストリームス(※)」。ゲームの結果もチーム戦ポイントに加算されるというルールでしたので、各チーム負けていられません!!

1日目に得点が低かったチームは一層気合が入ります。運営メンバーも各チームに1人ずつ入り一緒に戦いました。単純なゲームなのですが、運と確率論を駆使した戦いとなります。ゲームの特性上、トイレも我慢でしたがw 全員が本気でゲームをやるという貴重な時間となりました。 

※ 運営メンバーが息抜きの一つとして用意したボードゲームです。  

sgrk.blog53.fc2.com

1日目の夜 ハンターの気配を感じ続けた

夕食後は、部屋に戻り各自ご自由に~というスケジュールでした。チームごとの部屋割りになっているのもあり、ほとんど寝ずにバグハントされていたようで、翌朝までに多くの脆弱性が報告されておりました。朝PCを開いた時の衝撃は言葉に表せません。(この時初めて、ハンターの皆様がウーロン茶を飲まれていたことに納得しました)

日常を忘れてとことん出来た!!という声も多くいただき、夜中もワイワイとバグハンできるのは、合宿形式のメリットだと感じました。

2日目 ラストスパート

「合宿の得点として加算されるのは、11時までに報告されたもの」というルールでしたので、どのチームも最終日の追い上げは凄まじいものがありました。夜中に報告された分の評価が終わらないうちに、「新しい脆弱性が登録されたよ!」という通知が止まらない止まらない。。

f:id:cybozuinsideout:20171109172013p:plain

評価について議論する運営

評価チームが殺気立ちはじめ、2名体制から4名体制に変更し、ガシガシ評価していきました。それでも時間が足りず、重複チェックなどが甘かった点は大変申し訳なかったです。

最終成果発表

各チーム、スライドやデモを用いて、2日間で見つけた脆弱性について発表していただきました。そんな方法が...という内容も多く、おーー!といった感嘆の声があがっておりました。発見した脆弱性の情報、検出手法、悪用の手口などを共有していただくことで、運営側としても非常に勉強になりました。

f:id:cybozuinsideout:20171110162257j:plain

発見した脆弱性を発表する参加者

結果発表 

優勝賞品は、複数種類ご用意しました!それぞれにキャッチコピーがある点も運営のこだわりです。優勝チーム内で高得点を獲得した人から順に選んでね方式です。

1.Google Home「最高のバグハンターに、最高の室内環境を!」
2.Fitbit AltaHR  「適度な運動!元気なハンター!最高のパフォーマンス!」
3.AirPods         「生活をよりスマートに!浮いた時間でバグハント!」

そして、栄えある優勝は・・・Dチーム!!!!

1人少ないというハンデもあったのですが、チーム全員が報告しており、また、Masato Kinugawa さんの他を寄せ付けないパワーもあり見事優勝となりました!!

何かあると誰かの端末に集まって議論していたり、仕様に対するメンバーからの疑問にについて弊社開発者の横田も素早く回答していたりと、チームワークも素晴らしく納得の優勝でした。 

f:id:cybozuinsideout:20171109145500j:plain

Masato Kinugawaさん、raynoldさん、れっくすさん、横田智哉(Cy開発)

本部長 賞 (Google Home)

グローバル開発本部長 佐藤鉄平 が全ての報告を確認し、選出しました。「堅い堅いと言われていた kintoneの脆弱性を唯一報告した」という点が高く評価され、 llamakko さん に送られました!!

f:id:cybozuinsideout:20171114141538j:plain

報告された脆弱性を確認する グローバル開発本部長 佐藤鉄平

PSIRT 賞 (Apple TV)

一番影響度の高い脆弱性(CVSS v3 に基づいた評価値の最高得点)を報告した ゆったん さん に送られました!!

f:id:cybozuinsideout:20171109164426j:plain

バグハン合宿 を通して感じたこと

一同に集まることのメリットを感じた2日間でした。チーム戦にしたことで複数人での議論が生まれ、更に問題点を深堀りすることで報告件数の増加に繋がったと思います。開催目的の一つでもあった、バグハンター ⇔ バグハンター の交流バグハンター ⇔ サイボウズ社員 との交流も達成できたと感じております。

何より、24時間で48件の報告(内30件を超える認定数)をいただいたことに、ただただ驚きました。ハンターの皆様のお力に大変感謝しております。

さいごに

今年の報奨金制度は、12/20 で終了となります。制度の見直し、施策の準備期間を経て、来年度は4月頃の開始を予定しております。12/20を過ぎた脆弱性のご報告は翌年度の報奨金制度の対象となります。合宿を実施するかは未定ですが、ハンターの皆様にとって魅力的な施策を考えていきたいと思っております。

 

バグハン合宿にご参加くださったハンターの皆様、本当にありがとうございました!!現在、粛々と再評価作業を進めております。評価確定までもうしばらくお時間いただけますと幸いです。またいつかお会いできることを、運営一同願っております。:)

引き続き、サイボウズ報奨金制度をどうぞよろしくお願いいたします。

f:id:cybozuinsideout:20171109170945j:plain