Download as PDF, PPTX
![[db tech showcase Tokyo 2016] B15: サイバーエージェント アドテクスタジオの次世代データ分析基盤紹介 by 株式会社サイ...](https://cdn.slidesharecdn.com/ss_thumbnails/6i9kohhirrcoablwy2vg-signature-de1723da869232faf642797bf4411177191c3ef937923c1c3c4b18848e6dd30c-poli-160721053413-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Observability conference 2022/3/11] NewsPicks のプロダクト開発エンジニアが実践するスキルとしての SRE](https://cdn.slidesharecdn.com/ss_thumbnails/observabilityconference2022311newspickssre-220310143345-thumbnail.jpg?width=640&height=640&fit=bounds)
AbemaTV Developer Conference 2016
- 1.
- 2. @yasitashiki ● 板敷 康洋(Yasuhiro ITASHIKI) ● フリーランスのエンジニア兼開発コンサルタントとして、プロジェクト立ち上げや立て直 しの手伝いなど ● 2013年、(株)サイバーエージェントにサーバサイドエンジニアとして入社 ● 現在は、エンジニアリングマネジメントをメイン ● AbemaTVでは、開局前の障害対策／負荷対策を担当 自己紹介
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13. ● 現在開発中の某ソーシャルゲーム ● 開発中の成果物を確認したところ、iOS/Android間で仕様が違う。 ●また、αバージョンでリリース予定の機能も違う。 ○ iOSのみβリリース予定の機能が搭載されている、逆にαリリース予定の機能 が入っていない ● 状況整理し、軌道修正を手伝ってほしい。 依頼(初期情報)
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28. 仕様決定、伝達フローの整備 ● 仕様はプロデューサとチーフプロデューサの間で決定する。 ● 開発チームの窓口はプロデューサとする。 ●全ての仕様、修正依頼はプロデューサからエンジニアへ。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 仕様の共有 開発チーム 仕様の共有 仕様のずれなし ● 仕様決定、集約場所が明確に ● エンジニアへの情報伝達フローを一本化
- 29. 定期的な成果物レビュー会の実施 ● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。 ○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。 ○プロデューサも同席することでその場で仕様変更の決定を行えるようにする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 微妙なニュアンスを 直接伝える 定期レビュー会
- 30. 定期的な成果物レビュー会の実施 ● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。 ○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。 ○プロデューサも同席することでその場で仕様変更の決定を行えるようにする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 同時に聞くことで 認識のずれなし 微妙なニュアンスを 直接伝える その場で仕様変更決定 定期レビュー会
- 31. 定期的な成果物レビュー会の実施 ● 定期的にチーフプロデューサとエンジニアが直接対話する機会を設けた。 ○ チーフプロデューサの微妙なニュアンスがエンジニアに届くようにする。 ○プロデューサも同席することでその場で仕様変更の決定を行えるようにする。 チーフプロデューサ プロデューサ iOSエンジニアAndroidエンジニア 同時に聞くことで 認識のずれなし 微妙なニュアンスを 直接伝える その場で仕様変更決定 チーフプロデューサ介入の場を意図的に作ることで、 介入の影響を局所化した。 定期レビュー会
- 32. 学んだこと ● 意思決定、情報の集約は一元化しよう ○ 複数箇所で行うのは混乱のもと。意思決定者が複数いる場合、最終決定は 同じ場で行うことが望ましい。 ○また決定した内容の情報集約も一元化し、どこに最新の情報があるか分かる 状態にする。 ● 権力者とはうまく付き合おう ○ 介入が避けられない場合、影響を局所化する、限定的にするなど仕組みで 解決する。
- 33.
- 34.
- 35.
- 36. ● 某アパレルチェーンの在庫管理システム ● ウォーターフォールで進めているが、詳細設計で大幅に遅れている。 ●状況整理し、立て直し案を提出してほしい。 ● ちなみにチェーンの10周年に合わせるのでリリースタイミングは絶対動か せない。 依頼(初期情報)
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48. やったこと ● プロジェクトゴールの再設定 ○ 本来の目的である在庫管理に注力。レコメンドは第二期開発とすることにし た。 ○本来の目的「お客様からの在庫問合せに迅速に回答する」 ● やらないことの停止。第二期開発への引き継ぎ。 ○ 幸い在庫、レコメンドシステムともいい設計で、戻りはほぼ発生しなかった。 ○ レコメンドの設計は区切りのいい段階までやりきり、第二期開発用に引き継 ぎ資料として残した。
- 49. 学んだこと ● このプロジェクトで何を解決したいのか？目的を常に考えよう ○ 仕様が少しずつ追加される状態は危険なフラグ ●目的が変わるようであれば仕切り直し or 別プロジェクトとし、 スコープを明確にしよう。 ○ 途中で出てきたアイデアが良いものであればあるほど、クライアントはそこを ゴールとみなし、それ以下のアウトプットには物足りなさを感じてしまう。
- 50.
- 51.
- 52.
- 53. ● 某SNSサービスで、2ヶ月後の年末年始に大規模プロモーションをやること が決まった（CMなど) ● システムキャパが心配である。今も高負荷で頻繁にダウンしている。 ●プロモーションに耐えられるよう、100万同時接続にまでキャパを上げてほ しい。 ○ 当時のキャパは1.5万同時接続程度だった ● ちなみに、CMはもう決まったのでスケジュールは絶対守らなければならな い。 依頼(初期情報)
- 54.
- 55.
- 56. ● 耐障害性、可用性に大きな問題がある ○ 会員登録に関わる外部サービス障害時のバックアップがない ○特定機能の障害に引きずられて全体がダウンする 新たに判明した2つのこと
- 57. ● 耐障害性、可用性に大きな問題がある ○ 会員登録に関わる外部サービス障害時のバックアップがない ○特定機能の障害に引きずられて全体がダウンする ● プロモが大成功しても100万同時接続は行きそうにない ○ アクセス傾向とCM計画(ユーザ増予測)を検証した結果、最大でも30万 同時接続程度と推定された。 新たに判明した2つのこと
- 58. やったこと ● プロジェクトゴールの再設定 ○ 「100万同時接続」→「耐障害性、可用性、性能性とも、プロモーション に耐えるのに必要な状態にする」 ■同時接続数は30万目標 ■ 耐障害性、可用性で問題ある部分の解消 ● ゴール再設定に伴うプロジェクトスコープの再定 義
- 59.
- 60.
- 61.
- 62. 学んだこと ● あらかじめゴールが設定されている場合、まずはそのゴール が最適かの確認をしよう ○ 局所的な問題にとらわれず、全体を俯瞰して満たすべき要件を見極める ●炎上している時ほど、やることとやらないことの線引を明確に しよう ○ 周囲(社内など)がいくら盛り上がっていても現場だけは冷静でいることを心が ける
- 63.
- 64. ● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○権力者とはうまく付き合う。介入の影響を局所化、限定的にする 3つの事例で学んだことまとめ
- 65. ● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○権力者とはうまく付き合う。介入の影響を局所化、限定的にする ● 要件がいつの間にか進化する風景 ○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する ○ ゴールが変わる場合は別プロジェクトとし、スコープを明確にする 3つの事例で学んだことまとめ
- 66. ● 権力者の厄介な介入がある風景 ○ 役割分担(責任範囲)を明確にする ○権力者とはうまく付き合う。介入の影響を局所化、限定的にする ● 要件がいつの間にか進化する風景 ○ プロジェクトのゴールを明確にし、それにそった要件であるか常に意識する ○ ゴールが変わる場合は別プロジェクトとし、スコープを明確にする ● 大規模プロモ直前なのにシステムが落ちまくってる風景 ○ 具体的なゴールが設定されている場合でも、そのゴールが最適かの確認を改めて する ○ 炎上している時ほど、やることとやらないことの線引を明確にする 3つの事例で学んだことまとめ
- 67. よくある炎上パターンは他にも ● 組織的要因 ○ 主に人間関係などが原因でチーム崩壊 など ●技術的要因 ○ 実現できなかった、品質が上がりきらなかった など
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.