日本航空JL474便 / 高松発 - 東京(羽田)着

2023/08/13 8:30 AM RWY34 Landing

2023/08/13 8:33 AM Spot9

数年前に似た障害があったが、
ANAシステム障害 顧客DB同期処理失敗?
ANAシステム障害 顧客DB同期処理失敗? その2
今回は別の原因がらしい。

4月3日に発生した国内線システム不具合の原因及び再発防止策について

4月3日に発生したシステム不具合により、多数の国内線に欠航・遅延を生じさせる結果となりました。ご利用のお客様、関係の皆様に多大なご迷惑をお掛けいたしましたこと、深くお詫び申し上げます。

この度の不具合につきまして調査を行った結果、原因が明らかになりましたので、再発防止策とあわせてご報告申し上げます。

発生原因
国内線旅客システムのデータベースにおける、ソフトウェア不具合であることが判明しました。具体的には、予約管理業務のために、特定のデータを抽出する日常の処理において、ソフトウェアのバグを起因とするエラーが発生し、データベースサーバー2台が一時的に高負荷状態となりました。その結果、データ処理が滞り、サーバー2台が同時停止しました。

再発防止に向けた対応
（1）データ抽出方法の変更

（2）データベースサーバーが2台同時に停止しないための制御プログラムの強化

上記を確実に実施した上で、万が一、今後システム障害が発生した場合に備え、バックアップシステムへの迅速な切りかえ、訓練の実施などの対策を講じるべく、引き続き対応を図ってまいります。

DPEが最近流行っているようで、関連資料をメモしてみました。

DPE(Developer Productivity Engineering)が新しいソフトウェア開発工学の方法論で、ビルド・テストとCIなどの自動化ツールにフォーカスしています。その実践をDPEチームにより担当されます。
DPEとSREの違いは、SDLCフェーズの違いであって、DEV(development & test)開発生産性とOPS(deployment & maintenance)運用信頼性の違いだと思われます。
なお、DXE(Developer Experience Engineer)はDPEを実現するためのエンジニアロールの一つと自分が解釈しています。
ちなみに、GoogleのEngineering Productivity部門にDPEやDXEとのロールがなく、通常のSoftware Engineer (SWE)とTest Engineer (TE)だけあります。

4年前に開発生産性を考えるサービス化(API化)の本質はソフトウェア開発産業化記事は、DPEのようにツールチェーンのことを意識していたが、明確的に言葉定義として出てこなかったのが残念。

DPE - Developer Productivity Engineering

1 From QA to Engineering Productivity

Google Testing Blog Tuesday, March 22, 2016

In summary, the work done by the SETs naturally progressed from supporting only product testing efforts to include supporting product development efforts as well. Their role now encompassed a much broader Engineering Productivity agenda.

2 The Effect of Work Environments on Productivity and Satisfaction of Software Engineers
Brittany Johnson, Thomas Zimmermann, Senior Member, IEEE, and Christian Bird, Member, IEEE
2019/09

3 Developer Productivity Engineering: Introduction and Key Concepts

gradle.com By Dennis Welter
September 9, 2019

Hans Dockter, CEO & Founder of Gradle, talks about the emerging practice of developer productivity engineering, a discipline of using data to improve essential development processes from build/test to CI/CD.

Topics covered in this webinar are:

Quantify the costs of a low productivity environment with wasted time waiting for builds, tests, and CI/CD pipelines
Communicate the importance of fast feedback cycles and catching errors earlier, including incorrect signals like flaky tests
Discuss acceleration technologies for speeding up feedback cycles
Make the practice of developer productivity engineering a respected discipline
Use data to understand and improve essential development processes

ビルド、テスト、CI/CDパイプラインの待ち時間にかかる無駄な時間など、生産性の低い環境におけるコストを定量化する
フィードバックサイクルを高速化し、不具合テストのような不正確なシグナルを含むエラーを早期に発見することの重要性を伝える。
フィードバックサイクルを高速化するためのアクセラレーション技術について説明します。
開発者生産性エンジニアリングの実践を尊重される規律とする
本質的な開発プロセスを理解し、改善するためにデータを使用する

SailPointのアイデンティティ・プラットフォームとIdentityNowの違い

IdentityNow

1 SaaS-based identity governance platform
2 機能：
a プロビジョニング provisioning
b アクセス権申請・付与 access requests
c パスワード管理 password management
d アクセス権の棚卸 access certification
e 職務分掌/ポリシー管理 separation-of-duties

SailPoint Identity Platform

1 incorporates AI and machine learning into the core IdentityNow platform
2 機能
a アクセス権インサイト　Access Insights
b アクセスのロール権限定義　Access Modeling
c レコメンデーションエンジン　Recommendation Engine
d マルチクラウドアクセス管理　Cloud Governance

SailPoint Identity Platform機能概要

０、用語集
entitlement　権限、例：特定入室権限、ファイルアクセス権限、フォルダーアクセス権限
access profile　アクセス権限集（複数権限の集合、例Admin,　Guest）
role 役割・ロール
certification 棚卸
source 3rdパーティーのアプリケーションやDBなどのユーザー

１、プロビジョニング

プロビジョニングとは
プロビジョニングとは、必要なシステムやアプリケーションに対し、ユーザーアカウントの作成、変更、削除を行うことです。高度なプロビジョニングソリューションの場合、ユーザー属性のみにとどまらずアクセス権限も含めて管理し、アカウントを利用用途や業務上の役割に応じて運用し、IT部門の負荷軽減や管理業務の自動化に寄与します。

概要：
アプリケーションへの適切なアクセス権を自動で設定

機能：
a　プロビジョニングの⾃動化
IT部門のプロビジョニング作業は、各種アプリケーションに対する権限をロール（役割）ごとに付与する設定を事前にしておくことで、SailPoint IdentityNowが採用や退職等の人事情報の変更を検知し、役割に応じた権限を自動でプロビジョニングします。
b　権限の⾃動更新
権限の⾃動更新は、ユーザーの⼈事異動や役職変更などの⼈事イベントが発⽣した際、SailPoint IdentityNowで⾃動的に各アプリケーションに適切な権限変更を⾏う機能です。
企業では退職したユーザーのIDが各アプリケーションにログイン可能な状態で放置されていることも少なくありません。

Scaling Kubernetes to Over 4k Nodes and 200k Pods

PayPalはApache MesosからKubernetesへ移行しようとしていて、ただパフォーマンスチューニングでは大変苦労したことを記事にしてくれました。
Apache Mesosでは簡単に1万Nodeまでスケールアウトしましたが、Kubernetesでなかなか負荷テストが通らなかったそうです。色々やった結果は4000止まり。
ちなみに負荷テストツールはk-benchを利用していました。

テスト環境：
ーGCP
ーWorker Nodeスペック：4CPU、最大40Pod
ー規模：3つMaster Node、3つNodeのetcdクラスター、4100 Worker Node、20万Pod

服务网格数据面性能深度调优

1 default状態

あるFlame Graph調査では、sidecar のenvoyの CPU利用率の半分はKernel TCP/IP stackになります。

２ Pod内通信について、赤の１の部分をTCP/IP stackをSockopsに変換し、サービスとsidecar間のレイテンシは、10%低減。

データベースシャーディングアーキテクチャの新たな進化
DBシャーディング技術は自分としては20年以上前から使ってきたもので、枯れた技術の一つだが、トランスペアレントシャーディング(transparent sharding)について大変興味あります。
何故かというと、一旦shardingが決まったら、拡張のためのデータの移行が非常に難しく、実現性のある簡単な方法がないことです。

1 組織開発
1.1 MVV
1.2 組織開発
1.3 組織活性化の３要素：　人、仕組み、風土
1.4 タックマンモデルーチーム成長プロセス
1.5 変化の４つのフェーズ

2 人
2.1 能力の可視化
2.1.1 能力の３要素
2.1.2 能力の氷山モデル： 水面下の部分が水面上の部分を支えている
2.1.3 GE社の人材評価ツール9ブロック

2.2 キャリア
2.2.1 キャリアアンカー
2.2.2 Will/Can/Must

2.3 育成
2.3.1 人材育成のWill/Skillマトリクス
2.3.2 人材育成のフレームワークで最適な方法を選ぶ
2.3.3 コーチングのためのGROWモデル
2.3.4 経験学習モデル
2.3.5 動機付けしてモチベーションを高めるARCSモデル
2.3.6 ABC理論
2.3.7. ABCDE理論

2.4 リーダー
2.4.1 PM理論の４つのリーダーシップタイプ
2.4.2 リーダーシップスタイル(状況対応型リーダーシップ)

3 仕組み
3.1 コミュケーション
3.1.1 交渉のプロセスPRAM
3.1.2 報・連・相は職場コミュニケーションの基本
3.1.3 質問のフレームワーク
3.1.4 質問の種類
3.1.5 分かりやすく伝えるためのPREP法とSDS法
3.1.6 Want期待とCommitment貢献の可視化
3.1.7 会議のOARR
3.1.8 建設的に会話するSBIモデル
3.1.9 信頼を築くSBIIモデル

3.2 課題解決
3.2.1 課題解決プロセス
3.2.2 親和図法
3.2.3 ロジックツリー
3.2.4 ペイオフマトリクス
3.2.5 意思決定マトリクス
3.2.6 レーダーチャート
3.2.7 ディシジョンツリー
3.2.8 クロスSWOT分析

3.3 ステークホルダー
3.3.1 利害関係者の見える化
3.3.2 フォースフィールド分析

4 風土
4.1 ジョハリの窓Johari window
4.2 メンバーや他者を理解するためのハーマンモデル
4.3 メンバーや他者を理解するためのコミュニケーションスタイルモデル
4.4 トーマス＆キルマンの対立モード
4.5 ダニエルキムの組織の成功循環モデル

日本の空港チャートを整理し、空港ごとに一PDFファイルにまとめました。（2021年4月）
フライトシミュレーションや航空情報勉強用で、実際の飛行に使用しないでください。

The chart of airports in Japan has been organized and compiled into one PDF file for each airport. (April 2021)
This is for flight simulation and aeronautical information study, and should not be used for actual flight.

北海道地方
札幌飛行場RJCO Sapporo Airfield/Okadama Airport （丘珠空港）〔札幌市東区〕
新千歳空港RJCC New Chitose Airport 〔千歳市、苫小牧市〕
旭川空港RJEC Asahikawa Airport 〔上川郡東神楽町・旭川市〕
稚内空港RJCW Wakkanai Airport 〔稚内市〕
利尻空港RJER Rishiri Airport 〔利尻郡利尻富士町〕
礼文空港RJCR Rebun Airport 〔礼文郡礼文町〕
函館空港RJCH Hakodate Airport 〔函館市〕
奥尻空港RJEO Okushiri Airport 〔奥尻郡奥尻町〕
釧路空港RJCK Kushiro Airport （たんちょう釧路空港）〔釧路市〕
中標津空港RJCN Nakashibetsu Airport （根室中標津空港）〔標津郡中標津町〕
女満別空港RJCM Memanbetsu Airport 〔網走郡大空町〕
紋別空港RJEB Monbetsu Airport （オホーツク紋別空港）〔紋別市〕
帯広空港RJCB Obihiro Airport （とかち帯広空港）〔帯広市〕

東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について

2020年10月19日
富士通株式会社

東京証券取引所様に共有ディスク装置として納入した当社ストレージ製品「ETERNUS（エターナス） NR1000」において、メモリ故障に起因してデータを正しく読みだせない状態が継続する事象（以下、特定事象）が発生いたしました。

当該共有ディスク装置は一つの筐体内で二重化（1、2号機の2つで構成）されており、1号機においてメモリ故障に起因する特定事象が発生した場合、当該装置の有する障害時の切替機能として、2号機に自動切替が行われるはずでしたが、実際には自動切替が行われませんでした。

当該共有ディスク装置のマニュアルには、メモリ故障等に起因する特定事象が発生した場合は、必ず自動切替が行われる旨の記載がありました。

実際の製品では、設定によっては、メモリ故障等に起因する特定事象が発生した場合、自動切替が行われない仕様となっておりました。今回は特定事象発生時に自動切替が行われない設定になっておりました。

マニュアルの記載と実際の仕様の齟齬が生じた原因は、当該共有ディスク装置のオペレーティングシステムのバージョンアップにより製品仕様が変更された際に、マニュアルの記載が変更されていなかったことによるものです。

東京証券取引所様にて稼働中のOEM製品について、製品仕様とマニュアル記載内容の再レビューを実施します。また、製品仕様とマニュアル記述の一致、および仕様追加、仕様変更等の通知徹底等OEMベンダーと連携強化するとともに、当社として、OEM製品の評価プロセスを改善し、確実な再発防止に努めます。

Fujitsu Storage ETERNUS series NR1000 ネットワークディスクアレイ

NR1000 seriesは NASストレージ業界のリーディングカンパニーであるNetApp社のOEM製品です。
VMware仮想化環境における効率的な運用管理を実現するVSC（Console Storage Virtual)

自動バックアップ、5年間オフのまま　東証システム障害、富士通のマニュアルに不備

システム構築時に富士通側と検討した際、マニュアルには自動切り替えが動作すると記載されていたことから、実際の稼働テストを行わなかったという。

　テストを行わなかったのは、これまでのアローヘッドの稼働実績を鑑みた結果だとしている。東証の担当者によると、製品マニュアルから自動切り替えの発動パターンをメモリやCPUの故障、ネットワークの切断と想定していたという。
ネットワーク切断については切り替えテストを行ったが、メモリなどの故障については「NASの設定値とマニュアルの整合性については富士通内の製品出荷プロセスで検証されている前提だった」とし、テストを行っていなかった。

マニュアルに不備があったのは、機器を製造した米国企業の仕様変更が原因だという。2010年1月に稼働を始めた初代アローヘッドでは自動切り替えが「オフ」でも、トラブルを検知すると15秒後に予備に切り替わる仕組みだったが、2015年9月に導入した2代目からは「オフ」時にはバックアップが作動しない方式に変更されていた。

　これを富士通が把握せず、初期設定を「オフ」にして東証に納入。マニュアルにも反映されていなかったため、東証も気付かないままシステムを運用していたという。システム障害を受け、10月5日から設定を変更した。

東証は併せて、「システム障害による売買停止後の再開に向けたルールが整備されていなかったことも問題」として、証券会社など市場関係者で構成する「再発防止策検討協議会」を設置することも明らかにした。