Google Cloudは日本時間で6月13日金曜日の午前2時49分から約3時間のあいだ、Google Cloudの世界中のリージョンにおいてAPIへのアクセスに対して503エラーの発生が増加するなどの障害を起こしていました。
Google Cloud、世界中のリージョンが影響を受けた大規模障害、原因は管理システムがヌルポインタ参照でクラッシュしたこと － Publickey
報告によると、Google Cloud APIを外部に提供するために世界中の各リージョンに配置されているGoogle API管理ツールに追加した新機能に潜在的なバグがあり、適切なエラーハンドリングやフィーチャーフラグが働かない状態でヌルポインタを参照しクラッシュ。
Google Cloud、世界中のリージョンが影響を受けた大規模障害、原因は管理システムがヌルポインタ参照でクラッシュしたこと － Publickey
⇧ 影響範囲が広過ぎる...
「OWSAP（Open Web Application Security Project）」の公開しているドキュメントによると、
Aim & Objective
The goal of the OWASP Top 10 Proactive Controls project is to raise awareness about application security by describing the most important areas of concern that software developers must be aware of. We encourage you to use the OWASP Proactive Controls to get your developers started with application security. Developers can learn from the mistakes of other organizations. We hope that the OWASP Proactive Controls is useful to your efforts in building secure software.
⇧ 上記にあるように、『Validate all Input & Exceptions』とあり、『すべての入力を検証し、且つ、例外ハンドリングせよ』とあるので、本来であれば、「NullPointerException」を防止できる仕組みが確立されているべきなんだろうけど、まぁ、大規模な「システム」になると様々な「開発チーム」が存在すると思うので、「開発方針」とか統一されていないと思うので、「バグ」が埋め込まれるのも然もありなんという気がしますかね...
でも、「イミュータブル（Immutable）」な処理になっていないと、「入力」が頻繁に変更されることになるから、なかなか難しいですな...
今回の「障害」を起因に、「Google Cloud」内の「開発」における最低限の「全体方針」が定まったらしいが、「ガイドブック」とか用意しておいた方が良いような気はしますかね...
業務フロー図とワークフロー図の違いを知りたいんだが...
冒頭から、よく分からない情報が出て来てしまうのだが、ネットの情報を漁っていたところ、
- 業務フロー図
- ワークフロー図
の2つが登場するのだが、違いが分からない...
一応、「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」が公開している情報によると、
⇧ 上図から分かる通り、「業務フロー図」しか存在しないという立場のようだ。
と思ったら、
⇧ とあり、
- ビジネスプロセス関連図
- 業務フロー図
- システム化業務フロー図
- (a) 概要図
- (b) 詳細図
の4種類が存在するとある。
ただ、どちらにしろ、「ワークフロー図」については言及が無い...
ネット上の情報を漁っていたところ、
⇧ という違いがあるという立場の「情報」が存在した。
う～む...
「ワークフロー」は、粒度がよく分からない...
前回、前々回と、
⇧ 上記の時の記事で、「業務機能一覧」を整理する方法を模索していたわけなのだが、分類項目として「業務」しか出て来ていないので、「ワークフロー」は考えない前提で話を進めることにする。
業務フロー図でスイムレーンを用いて関連するシステム、担当者といった登場人物を俯瞰で整理したいが...
で、「業務機能一覧」によって、「業務」が洗い出せた後に、各々の「業務」の詳細についてを整理する必要が出てくるわけですと。
なのだが、まずは、各々の「業務」に関連する、
- 作業（タスク）
- 担当者
- 環境（社内/社外など）
- 媒体（アナログ/デジタルなど）
- I/O（Input/Output）
などについて全体像を俯瞰で把握したいですと。
イメージとしては、
⇧ 上記のPDFを参考にした場合、
⇧ 上図の「スイムレーン」の1つについて、詳細化するような感じ。
「スイムレーン」の粒度が変わって、登場人物についても若干の詳細化が行われることになるので解像度が上がる感じになるかと。
複数の「業務」が混在している感じになってしまっているのだが、
⇧ 上図のような感じで、
- 作業（タスク）
- 担当者
- 環境（社内/社外など）
- 媒体（アナログ/デジタルなど）
- I/O（Input/Output）
といった、「業務」に関わりが深い登場人物を俯瞰的に整理する感じ。
このあたりの「情報」がハッキリしていないと、「業務機能一覧」で洗い出している「機能」との対応がイメージできないことになって、開発がスムーズに進まなくなることが往々にしてある。
開発する「機能」だけで考えた場合、最低限
- インプット（I/Input）
- 取得元はどこになるか
- インターフェースはどうなっているか
- 項目数
- 各項目のデータ型
- 各項目の制約
- 必須/非必須
- 固定長/可変長
- 許容する最大桁数/最小桁数
- 日時のフォーマット
- チェック処理の要否
- エラーにするのか/しないのか
- 処理
- どのタイミングで実行されるのか
- 同期/非同期は影響してくるのか
- どのタイミングで実行されるのか
- アウトプット（O/Output）
などは把握できている必要があるので、登場人物に関しては、「MECE（Mutually Exclusive and Collectively Exhaustive）」的な感じで、漏れがない状態になっているのが望ましい。
「ソフトウェア開発」の「上流工程」って、情報が錯綜し過ぎなんよな...
「成果物」の抜け漏れの問題以前に、「成果物」の「標準化」して欲しいところですな...
「プロジェクト」によっては、「業務フロー図」を作成しないという方針もあるのかもしれないが、登場人物の関係性を可視化せずに作業を進めると「空中戦」が展開されて、結局のところ、「認識齟齬」が頻発することになる気がしている...
あとは、「BABOK（Business Analysis Body Of Knowledge）」の思想で見た場合、
⇧「業務フロー図」って、「ビジネス」寄りの話が気するので「要求定義」で作る感じになる気がするんだけどな...
少なくとも、「要件定義」の作業では無いような気がするんだが...
そのあたりも、ハッキリした情報が無いのが困るのよね...
とりあえず、「独立行政法人情報処理推進機構（Information-technology Promotion Agency, Japan、略称: IPA）」には、「ソフトウェア開発」の「ガイドブック」を整備して公開して欲しいところですな...
いつまで経っても「我々は雰囲気でソフトウェア開発を行っている」の状態から脱却できなくて、ストレスが溜まるだけなのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
