Lion Air 610和Docker+Consul

有時啲自動嘢太懶醒就出事

第一架炒嘅波音737 MAX

JT610喺2018–10–28由印尼雅加達起飛之後，飛行高度如過山車一樣唔受控制，機師中途曾要求折返，但最終喺起飛13分鐘後墮海。據離墜機地點幾公里遠嘅鑽油台工作人員目擊指，飛機差唔多係直插落海。全數乘客連同機組人員共189人無一生還。

(默哀)

渉事飛機 (by PK-REN)

737 MAX係2016年先至投入營運嘅新型737型號。呢一架更只係有兩個月前先投入使用，只係飛咗800個鐘。

波音737 MAX機頭。4個15.1吋大mon，可以睇得出呢架嘢係幾咁現代化

2018–11–07印尼國家運輸安全委員會指，飛機途中冇解體、冇爆炸、冇火災、非恐襲。黑盒記錄顯示，飛行途中左面攻角感應器異常，同右面感應器嘅讀數相比曾出現達20度嘅誤差，引致左側飛行電腦誤判以為攻角太高，以為飛機已進入失速狀態。

攻角 (Angle of attack)，即機翼翼弦(Chord)同氣流間嘅夾角。如果角度大到一個臨界點，機翼就提供唔到升力，為之失速。

波音737上左同右嘅感應器、訊息以及飛行電腦都係獨立分開，喺呢單嘢，坐左面嘅機師會睇到個風速計亂哂大龍跳哂針，坐右面嘅副機師會見到好正常。而控制飛機俯仰(Pitch)角度嘅控制面，係由左右電腦共同混合控制，所以是但一部電腦郁都會有反應。(Rolling control方面則係左面控制aileron，右面控制spoiler)

為防止失速，左側飛行電腦不斷發指令指使機頭向下，目的係想降低攻角。呢個係一個737–8/9 MAX系列先至新增加嘅程式，波音解釋因為新引擎重咗而更易失速，所以要加多呢樣嘢FAA先會核批 (Certify)，但係出事之前全球冇一個機師知道有呢一個機制，手冊都冇提過。

波音機嘅理念不嬲都係機師主導控制，除咗你叫佢做(如autopilot)，好少嘢電腦直接干預。喺舊版嘅737中，失速時只會有Stick Shaker等警報 (MAX都有)，但都係要靠機師主動撳低機頭去恢復。

同日，美國聯邦航空管理局發出咗一份相關嘅2018–23–51號緊急適航指令，雖然調查未完成，事故很可能就係因為呢個電腦誤判以導致。

737控制俯仰角度(即係上下)係由兩樣嘢控制 — 升降舵(Elevator)同埋水平尾翼配平(Stabilizer Trim)。

成塊水平尾翼可以調校角度 (紅線示)，以便配平，黑點係機身上嘅標志表示調校極限位置，機頭向上(即翼指向地)極限十度、機頭向下極限五度。升降舵係橙色箭頭所指嘅一塊控制面 (Control Surface)，左右各一。

升降舵係將操縱杆(Yoke)推前或拉後去控制。如果想飛機永遠保持一個飛行府仰角度唔用力，就要調校水平尾翼去配平。配平之後就唔使扯住個Yoke，慳力慳精神。

自動飛行系統(autopilot)亦會控制升降陀同埋配平達到預設嘅航向同姿態。

人手做配平有兩種操作方法：

1. 通過操縱杆外側的開關去電動控制
2. 人手轉動配平調節輪。當然一般都好少用得著。
   注意由自動飛行系統郁或者操作電動配平嗰陣，呢塊鐵餅都會自己跟住轉。

喺操縱杆外側嘅水平尾翼電子撥片開關（橙箭頭示） by golfcharlie232。從後面嘅面板見到呢個係上一代嘅737 NG，不過個Yoke嘅設計就半個世純無變。

黑色塊鐵餅就係配平調節輪 (Trim Wheel)，在中控台兩邊都有一個。嵌喺裏面嘅手把可以放落來方便人手轉動。橙色所示嘅係切斷電動配平和自動飛行系統配平嘅開關。

講返同日美國聯邦航空管理局發出嘅2018–23–51號緊急適航指令，裏面指出737–8/9出現單邊攻角感應器異常嘅判斷準則同埋要採取嘅措施。

AD 2018–23–51的應對方案

而應對方案係，先解除自動飛行並用操緃杆同操作電動配平去控制仰府姿態。若然配平位置還繼續動，把電動配平系統切斷。若然還是失控，則人手阻止配平輪轉動並加以調整。

睇到最後一句感覺有啲恐怖 😮 雖然話係cutoff都唔得嘅後備措施，但睇下🎬呢條片教人點樣揸實一個暴走到發發聲嘅配平調整輪真係嚇死街坊。如果喺空中要做啲噉嘅嘢，都幾恐怖。

希望波音快啲有永久解決方案…

Docker+Consul

Docker就眾所就知啦，如果你係Devops而冇聽過呢樣嘢……🙈🙈🙈

繼Blockchain之後最流行嘅Technology (沒有之一) — Container-based Virtualization

Consul係一個分布式服務發現和鍵-值儲存系統，argh我放棄樣樣嘢譯中文嘞，我指— Distributed Service Discovery and Key-Value Store。有ZooKeeper嘅service discovery功能，亦有etcd嘅key-value store功能，而且discovery同resilience check係靠nodes peer-to-peer去做，減輕server負擔。

三年前(2015–07左右？)，我將公司套主要系統轉成Docker。當時Kubernetes都未v1(又或v1冇耐)，docker swarm v1並無跨node networking功能。所以我加埋Consul同haproxy搭起套infra—用consul去監察app container readiness，加上KV store做blue green deployment，夾埋consul-template去動態調整haproxy config。

HashiCorp出品嘅Consul

但冇幾耐之後就發然consul喺NAT下係short嘅 — 佢個consensus protocol會期望keepalive個source port等同incoming port。我放個consul入container再expose個port，喺底下即係由個host做NAT，SNAT時對應嘅source port可能已經被佔用就以就會分配另一個port，噉就炒粉。Repro好容易，docker restart個container就得，事源舊嘅translation tuple喺conntrack裏面未timeout，一定會分配出另一個source port。出問題嘅話，個consul就會跳哂掣，有啲nodes之事冇contact過嘅就見佢冇事，但又有啲nodes條conntrack仲喺度嘅就以為佢死咗，無限loop。

相關問題ticket喺github上傾咗好耐，有好多人report，但跟咗一年官方最後嘅答覆係「係噉㗎喇 by design」然後close ticket，真係睇到眼都凸。

過多一排，docker就support overlay network。overlay network上面嘅interface就係無需轉換嘅「真IP」，唔使經NAT。所以我將套consul轉到呢個overlay network上面。但overlay network本身亦都要KV store運作㗎喎，docker可以揀用etcd又或consul。噉用開consul更係繼續用，所以「外面」(bare metal上)又搭咗套consul去做呢樣嘢。

一內一外兩組consul，用vxlan，加上出咗名新版breaking changes多過食飯嘅docker，無礙係個黑箱作業嘅計時炸彈，但洗濕咗個頭就用住先啦。

VXLAN — 一層冚一層，俄羅斯娃娃

相安無事直到……直到前排再scale up的時候……

overlay network出問題！

某啲container經overlay network ping唔到某啲container。結果會導致container明明up都被consul認為係down，又或者flip來又flip去，load balancer亦因此不斷reload config而出問題。另外亦令container去唔到KV store，拎唔到application config。

問題點repro？唔知。乜原因？唔知。更加唔知有乜解救。乜都唔知嘅情況之下當然係reboot試下。我reboot哂所有overlay network consul同docker nodes……

唔得。

我drill down到佢用嘅vxlan，用過tcpdump睇過，source container ping出去見到，但另一邊就收唔到，都唔知點解。去到呢個位，我都唔知係consul定係vxlan問題。

問題迫在眉捷，講得要scale up梗係急住用啦。啲嘢硬係急住用先來壞（好似港鐵噉？）

把心一橫用docker network disconnect甩開啲container，再docker network rm咗個overlay network，跟住將consul上docker用嘅KV剷咗去。重零開始搭過哂，正常返……

……正常返24小時噉多！然後又死過。

最後？真係cut哂佢，依賴KV Store嘅就改為人手擺個static file上container，deployment要手動改haproxy config。唉，捱過咗呢期先至再算。

呢種感覺就好似要人手揸住個配平調整輪，同呢啲黑箱自動系統抗衡。系統一層包一層，有起事上來越來越難Debug。

anyway，大概會轉會用Kurbunates。