我是個Car Guy，來北美第一台車本來打算買電車，我與電車的距離，只差sales是否點頭同意我的報價，可惜我被拒了，最後還是俗套買了一台二手油車。

前陣子看到網紅Terry說：『現在買車，2年後可能價值歸零』(因為沒有FSD)，所以有感而發，也許未來可能真如他所說，但只給2年年限好小氣，也太標題黨了XD

自動駕駛

我曾經擁有的兩台車都有Level 2輔助駕駛，可以說半斤八兩一樣雞肋，使用場景只有兩種：高速公路跟車和塞車。

更Generic的說，反正就是前面有車，你得跟著。

我對特斯拉的FSD非常肯定，看影片looks way better! 唯一有意見的是行銷用語，我看到『每英里事故率比人類駕駛低』就像看到資料庫100% up-time差不多。

最近聽到M觀點Podcast分析FSD的每英里事故率，並拿來和人以及Waymo對比 (FSD數據是人加FSD）。主播有補充不是apple to apple comparison，不過是在前面已經說了一大段FSD比人安全七倍之後，整體聽起來就是『數據佐證，FSD比較安全』，總之這段聽完我感覺是相當違和。

我倒不是認為FSD不安全，也不認為主播不理解其差異，思考了一些時間，我的推論是這樣，由於：

1. FSD各種user feedback都表明他是真真棒
2. Robo Taxi的快速rollout，也側面驗證了無人駕駛的FSD，應該有很不錯的水平

綜上得出一個很高的信心水準，這個信心大到足以認為真實的apple to apple comparison數據也會差不多，所以遷移認同了FSD比人安全七倍和與Waymo程度相當的說法。

回望我過去曾看到的軟體業假數據案例，似乎有是一個可能的解釋，大概都是對自己的project信心巨大，淺意識中認為即便數據算法不對，但也算反應了真實狀況。

車子不僅僅是車子

我們常常聽到對於花錢的建議是，購買體驗帶來的幸福感遠大於購物。網路上也常常有人建議，車子是負資產，最好的做法是買Toyota開20年。

另一方面，不知道在哪部電影看到，它說黑道大哥都戴勞力士，因為跑路方便：體積小，攜帶方便，保值，流動性高。

對於Car Guy來說，擁有喜歡的車帶來的幸福感是大於純買體驗的，又或者，開車本身就是體驗。如同黑道大哥的勞力士，車也有著交通工具以外的附加價值。

我剛來加拿大還沒有車，很常用一個叫Modo到car sharing服務，很有趣的是，他有各式各樣車款，油車/電車/油電全都有，不像irent都是小鴨，從買體驗的角度來看，非常划算！

由於是car sharing，車種都是以經濟型為主，有新車也有舊車，我的統一感想是開高速直線前進時，總是需要時刻細微調整方向盤，沒辦法穩到非常順心。總算比較能理解車評為什麼總是打高空，雙B的底盤確實比較『紮實』。

時代的洪流

我很喜歡周星馳的電影，特別是龍祥電影台會反覆重播的那些，那些周星馳自成一格的戲劇風格，用朗道五級工程師的分類來看，應該穩坐L2，即開創了前所未有，難以被取代的產品。

時代無法複製，當時的技術限制反而催發出很多有趣的創意，在技術很好的現在，單調的追求華美與高畫質更顯得平庸。

電動車也是大勢所趨，以後的世界應該只剩下高階油車給富人作為稀有與象徵浪費的玩具。缸數即是正義R.I.P.，但汽車長久下來產生的文化遺產應該不會這麼快消失，現在的性能電車，在感官刺激上總是在模擬油車，換檔的衝擊，排氣聲浪等，不如摻在一起做FSD+VR賽車？

這期蹭一下最近炎上的議題：職場霸凌。

碰巧近期也在萬維鋼的精英日課學到相關知識點，幫助我梳理了想法，也學習到一個實驗，可以為現狀提供一個很好的解釋性。

勞動部的洞見#1

上一期我們提到成長型管理風格V.S.固定型管理風格，其中固定型管理風格會傾向以恐懼建立威信，用嚴懲來嚇阻犯錯，而這種集權式的做法，不可免的為走極端提供了一個溫床。

我們之前也說到具體要拿捏好度，但卻沒說怎樣算好怎樣算不好，為了避免被當成是『在非洲，每六十秒，就有一分鐘過去』的幹話，這裡必須提供一些可實操的原則來避免走極端。

其實，上個月的勞動部調查報告已經為我們提供了一個教科書式的標準答案了，你們參酌其中這句對署長管理風格的評語：

『執行方式過度嚴厲，忽略人文關懷』

這句話不就是在告訴我們，一個合理的度就是，嚴格的管理必須基於愛與關懷嗎？

球隊教練是很好的例子，電影卡特教練中教練對球員的指導與要求是嚴格的，但你可以從具體的要求背後讀出愛。比如：不能說髒話；學業成績不達標時禁止參加訓練和比賽；比賽當天必須穿西裝打領帶。這些針對品格的要求，是愛的體現。

不過，可以想見的是有些富含深意的嚴厲指導不見得好理解，你大概可以猜到球員會質疑穿西裝和球隊奪冠有什麼關係？這種個體理解的差異，只能在一系列one on one(一對一對談)中提升相互的理解來解決。但基本道理是，嚴厲的管理不應該對人格造成負面影響。

勞動部的洞見#2

勞動部調查的另一金句是某員『立意良善』，再輔以上面球員的例子，我們可以發現由於『立意』本身解釋性不佳的特性，背後往往有很多操作空間。一個很俗套的例子是：我罵你是為了提升你的抗壓性。但如果我們都知道辱罵對管理是有害無利的，又何必捨本逐末去訓練這種抗壓性呢？

話題走到這，一個不可避免的問題是：
還是有很多成功的企業與管理者，或多或少就是這樣的管理風格呀，如果這是社會常態，我就得適應不是嗎？

凡是現實都是合理的

要回答這個問題，就得先講講開頭提到的，從萬SR那學到的實驗講起。

簡單來說是這樣，實驗把學生依照不同管理風格以及最終工作成果分為四組，其中霸凌管理組的主管會說類似這樣的話：你們好好幹，不要給我提一些沒有價值的爛點子，浪費我的時間云云～然後分析團隊成員對主管的評價：

實驗發現，不論如何只要提案獲得成功，團隊都會對主管有比較好的評價，尤其團隊1成員會認爲主管這麼做是為了團隊的成功，『立意良善』。

這個實驗解答了為什麼現實還是長成這樣，一個公司只要在商業上取得成功打下良好的基業，或許還搭上了AI順風車，那成功多半能彌平那小小的管理debuff。

但是，我們如果就這樣簡單接受這個現實，就相當於退回去用固定思維的思考模式了。

菲利普津巴多的洞見

菲利普津巴多是美國著名心理學家，曾主導著名的史丹佛監獄實驗，他發現：

1. 環境對人的影響極大，絕不可小覷
2. 人可以透過有意識的主動改變環境，進而改變人

有了這一層認知，我們不妨這樣思考：我是比霸凌主管更高級的人，他成為這樣的人是因爲沒能戰勝環境，我，可以改變環境。

具體改變環境的操作可以由小到大，或者說就應該由小到大：

1. 改變內部環境：先嘗試在公司內部和人資、友team主管、或skip溝通，一般來說只要用問題諮詢或提建設性意見的角度說，且態度良好不堅持己見，即便嘗試失敗或不被認同，也不太需要擔心太多負面影響才是。
2. 換個環境：通過1你可以獲得資訊判斷這件事是屬於可以改變還是不能改變的。更重要的是，通過1你有機會知道這個環境是across the company還是零星個案。不能改變的狀況下，你可以判斷是換team好，還是換公司好。

由小到大的好處是，我們對問題始終保持積極性和主控性，而不是碰到問題就逃避。而嘗試對超越自己可掌控的事物做出改變這件事，本身也是一種學習成長的好機會。另外，Feedback總是雙向的，從更高維度來說，你做出了貢獻。

最後，我想再次談回眼界這個話題。

前面提到如果社會常態就是這樣，那多半得適應了。但我們說的社會常態是一個組織的常態，一個產業的常態，還是一個世界的常態呢？如果把尺度放大到全世界，會不會我們說的常態其實是？

前陣子泰坦號很紅，蹭一下流量。根據我不負責任了解，眾多專家事前就有給出各種造潛水艙的專業建議了(邊界)，但不清楚自己在哪的CEO就想著創新，落在腳點就在邊界之外了，自然是很難成功。

案例分享

我最近夢到某公司有一套舊系統運行多年，不斷有一些小incident，也有些性能瓶頸。然後某A團隊旱地拔樁，直接建了一套新系統，號稱是各種神，就像大數據系統永遠是high throughput, low latency, 100% uptime！？

A團隊開始到處推銷自己的新系統，並詳細列舉舊系統過去發生的各種incidents鞭屍，且稱自己的新系統更安全，性能也高一個量級，甚至在某一次舊系統又出小問題時，直接在公頻開嗆舊系統趕快退出下線，不要再打壞同類型系統的名聲了。

後來舊系統下線沒多久，新系統就出包了，而且先發上場就是個隕石包！因為新系統性能高一個量級，災害等級也直接提升一個量級，原本舊系統出問題時頂多影響一個關聯系統而已，新系統則是直接影響一千個！量級的問題在於，一個系統出問題可以很快讓PE用operational手段修復，一千個沒有腳本是做不到的。後來新系統就被叫停了，並要求所有功能都要有對應都要有自動修復腳本，開發成本也直接飆升一個量級，加入了開發維運成本和風險等級再評估，新系統到底有沒有比較好？成本效益如何？兩說。

凡是現實的，都是合理的。當你覺得別人都是白癡你最聰明時，99.99…9%你一定是錯的，剩下0.00…1%是天才。回顧一下泰坦號和軟體開發的例子，其實道理都一樣，所有事物不外乎都是平衡與tradeoff的結果，很多時候超出邊界都是認知不夠。在需要考慮多個維度作tradeoff時，少考慮了。

怎麼知道自己在哪？

玩遊戲最棒的一點是有狀態欄，可以看自己現在等級多少，甚至還差多少經驗到下一級，有什麼技能，技能等級多少，你在哪，看一眼狀態欄一清二楚。現實生活我們沒有狀態欄，也根本沒有量化等級經驗值這種東西，但有一個簡單的辦法，雖然沒有絕對數值，但我們可以排出相對位置。

宏觀來說，Individual Contributor(IC)的職業階梯(SWE I, SWE II, Senior, Staff, Principal, Distinguish, Fellow)和組織管理金字塔(Manager, Director, VP, CXO)還是相當靠譜的，即便同等別好了，團隊中相對高低的排序大家肯定也是心中有底。高級別的人講話不一定都對，而且有時候只是在多個都可行的方案中選定一個讓所有人對齊，但會是很好的參考，重點是透過高級別人的見解盡量拓展認知邊界，把未知的未知(不知道自己不知道)變成已知的未知(已經知道自己不知道)，後者在判斷風險可行性上有大用。

更高級別的人往往見識與多維思考的能力會好很多，比如系統共用/centralization永遠是軟體開發一面經久不衰的大旗。但是Conway’s Law告訴我們組織架構決定系統架構，系統共用最終還是會碰上goal不同不相為謀的困境，也就是溝通協作成本大於軟體共用的效益。怎樣strike共用的 balance是管理的藝術，而至少管理過兩個團隊以上的人會很快認識到這個維度的問題，並開始鍛鍊這方面的決策能力。

疑？這樣說來，組織不是應該把超出邊界的風險管理掉了嗎，怎麼還是經常發生？

等級只是粗分，能力需要細分

很多初階主管很容易掉入的一個陷阱是，一但升了主管就覺得自已什麼都行了，一個經典的外放表現是『我不懂是你的問題』。實際上主管肯定會在某方面能力很行，但也肯定有不行的部分，這時候就需要仰賴自己某領域很行的能力，搭配member在新領域的具體經驗 = 遷移至新領域的能力。不過一但碰到的sir是『我不懂是你的問題』公式顯然就不成立了，有時候高級別的IC也會有『我什麼都懂』的大頭病，彼德原理也無時不刻在發揮作用。

應對風險的辦法和分散式系統無異，就是增加冗余。除了report line上能收到的feedback，最好在公司內找到其他高級IC幫忙定期mentoring(bi-weekly, tri-weekly, monthly)，詢問技術社團/slack group的具體意見，或者在公司外有認可的專家好友可以做技術探討(注意保密)，都有助於彌補團隊在細分能力上沒有足夠能力判斷邊界的風險。

Senior做事總能認知風險，包含自身能力不足的風險，並leverage適合的專家mitigate風險。有了這一層制衡思考，至少就不會在歧路上越走越遠。

去年底工程師裁員潮開始時，我揣著坎克不安的心情relocate到溫哥華做打工仔。通常這種開啟人生新篇章的事件，大部分人都是抱持美好的想像與期待，不過我的劇情很快就急轉直下。不開心是肯定的，不過轉念一想，我的雖事如果能讓大家莞爾一笑，也算是一種美談不是？

第一章：SIN

登陸加拿大之後最先要做的一件事就是取得Social Insurance Number(SIN)，記得是有規定登入3天內要取得，總之relocation consultant安排了登陸兩天後帶我去辦，一切乍看很令人放心。

兩天後一早7:30我們就去Service Canada排隊，好像是8:30才開門，我們取得了頭香，本來以為殺雞用牛刀，太早到了，結果不一會一大群學生被帶隊過來排隊後我就很慶幸有這麼早到。

將近開門時間時政府工作人員用急促的語氣安排大家準備進入辦理，給人感覺就是我今天絕對不要加班你們快點。我和老婆是第一個，先上去分類帽櫃檯說我們要辦SIN，然後被問了要一起辦還是分開，他說分開會比較快，那當然是分開辦理囉。

我很快被帶到一個房間，然後辦事員開始問我各種資料，加拿大地址、父母姓名(記得先記好英文護照版)、生日等，然後就開始不對勁，辦事員像是在質問的口氣問我真的是第一次辦SIN？真的是第一次來加拿大？真的沒有線上辦過？然後我就被嚇得一愣愣，說可能有線上申請的attempt，但沒送出過之類的，總之最後因為她現場辦不下來，所以幫我填表後送head office，也就是轉成郵寄申請。

我被搞得很緊張也弄了很久才出來，我老婆倒是一下就辦好了。我問consultant沒有SIN我還可以工作嗎？我下週一要上工了。他就打電話問一下同事，然後斬釘截鐵說不行。接著consultant帶我去逛逛周邊的地理環境做介紹，一路上我全無心情…

之後回家我趕快查官網，雖然是說要3天內取得沒錯，不過如果3天內有送出申請處理中也是OK的，瞬間覺得consultant真的很瞎，不懂別亂嚇人，害我不斷想像非法工作被遣返之類的劇情。

但沒有SIN還是很大問題，後來我一直打gov hotline問，早上8:30準時打進去是不太需要等的，但只要慢一點就有得等了。如果跟辦事員說你已經開始工作需要薪水生活之類的，是可以請他們幫忙提高priority的，不過我也是很後期才知道。最後我焦慮了半個月之久，總算電話問到已經處理完畢approved，放下一塊心中大石。雖然還是不知道為什麼就是了，我的理解99.9%的人應該是當場就可以辦下來。

第二章：Tech Equipment Delay X Payslip Combo

由於我是fully remote role，筆電手機等工作至關重要的設備都是郵寄的，也不能事先寄給別人代收，總之我正式onboard時都還沒收到，雖然公司都說沒關係等收到再開始工作即可，不過中間一樣是滿焦慮的整天refresh shipment status…

後來我是onboard date過了8個工作天之後才收到筆電，趕快上內網填寫各種個人資訊。我發現payslip寫sign-on bonus已經發了，可是我都還沒填我的銀行帳號耶，怎麼發的？

發ticket一問才知道因為沒填bank info，他自動fall back成紙本支票寄出了。後來我就一直等，每天信箱開爛，反正等了一個多月最後也沒收到過這張幽靈支票。中間是當然是各種焦慮，因為sign-on佔薪水不小的比例，而加拿大稅又重，本來是2022的收入如果拖到2023收到，被算做2023收入，會要扣一大筆稅繳給政府。

因為要趕2022收到，兩週後我覺得不對勁就趕快發ticket申請改存銀行帳戶而不是支票了。這個需要先支票stop payment，收到銀行退款再改存銀行帳戶，總之又多等了一個半月。幸好公司有確認是算做2022收入，但中間焦慮蔓延的時間自然也不在話下。

第三章：神啊請給我電梯

一月開始要搬入新租的公寓，公寓要搬家或買傢俱送貨都需要先預約電梯，我的床組和沙發是在The Brick買的，前一天接到電話確定送貨時間我就趕快下樓找Concierge預約，不過她回我說明天送貨時間再來找櫃檯說就可以了。

到了明天，接到送貨電話後我就下樓找櫃檯，結果她跟我說電梯已經被預約走了(心中無限OX)，但貨都送到了也只能硬著頭皮等客用電梯，果不其然超難等，因為其中一台電梯已經被預約走了啊，雖然最後勉強還是送上去了，但也浪費很多時間，搞得所有人都很躁。

後來我也有滿多事情需要找Concierge協助，雖然Concierge是24X7，但只有白天上班時間的Head Concierge會處理事情，其他時間的人都是能推就推，真的非常瞎。

因為我陸續還有其他家具需要送貨，所以心想吃一次虧學一次教訓，到時候預約要堅持把時間訂下來。不料，等到我真的要送貨前幾天，公寓8樓重新裝修不慎把灑水頭弄爆了，導致8樓以下都做水災，三部電梯有兩部壞掉，因為只剩一部電梯所以不能預約電梯了，我也是非常無語。

第四章：薛定諤的送貨時間

電梯壞掉後，雖然其中一部搶修好了，但Concierge只給一天一組人預訂電梯quota，所以搬家還是非常卡。我從台灣也運來不少東西，送貨團隊給我送貨時間後，我還需要確認電梯是否能預約，結果這個團隊很搞笑，我只是說我要先確認電梯，他們就先取消原定送貨時間，後來我確認電梯可以回覆給他們說可以送貨，他們也就沒回覆了。

結果等預定時間到了，他們說沒有送因為已經取消了，這其實也沒關係，我們就再訂另一個時間送，不過這次他們給的時間我預約不到電梯了，就回他們不行，我們再等可行的時間吧。

誰知Surprise!!!

等到了那個說不行的時間時，送貨人員突然打給我說已經送到了，我跟他們說可是沒預約電梯耶，他們說沒關係他們等客用電梯慢慢搬，雖然我是沒差在上面等就好，但是這個薛定諤般的送貨時間實在是讓人猜不透啊。

第五章：Secured Bike Room？

溫哥華市區對腳踏車還算滿友善的，有設計專用的腳踏車道，但高低起伏還是不小，所以很多人會選擇騎有電動輔助的E-bike，E-bike也是很多吳柏毅的最愛。

我也買了一台可以雙載的E-bike，作爲我和老婆的短距通勤手段。E- bike其實都滿貴的，所以我都是把腳踏車牽進房間放，直到有一次被白天有在做事的Head Concierage看到，他就跟我說公寓規定腳踏車是不能帶上樓的，然後帶我去了公寓的bike room，說有門禁管制只有住戶可以進出，之後就把腳踏車放這，並且把車鎖好就可以了。

我逛了一圈bike room就覺得毛毛的，說腳踏車墳場還比較實在，不過還是只能硬著頭皮放這了，後來果不其然，第二週我腳踏車上的手機支架就被幹走了！這種配件是用手轉上去而已，實在很難防止被偷。第三週某天我下去牽車，又發現椅墊明顯被轉過，有點像是要偷我椅墊下的電池但沒偷成。總之腳踏車放在bike room每天都很怕被偷，焦慮X焦慮X焦慮。

支架被偷後我再次詢問公寓管理員安全起見是否可以帶我的E-bike上樓，他回覆用袋子裝起來就可以提上樓進房，試問到底誰會用袋子裝腳踏車提著走？順帶一提，因為電動滑板車是比較新出現的東西，沒有寫進公寓管理規章，所以大家都是直接嚕進電梯上樓。公寓管理員這種官僚推諉避事的做事方式，實在也是世界通用啊。

後記

4天前公寓公告修水管，9–36樓的冷熱水都停止供應，公告是說只有那天白天沒水而已，結果那天到很晚水才姍姍來遲，不過也只有廚房水恢復正常，浴室只有涓涓細流，隔天詢問Head Concierage，只是淡定說等兩三天才會恢復正常拉～！

今天，洗澡還是只有尿尿小童的水量。

最後總結一個最高心法：虛實並進。

自己要利用虛實組合建立story提高賣價，也要清楚知道對方也在虛實之間擺弄殺價，永遠保持警惕，不論聊得多開心。

建立虛底牌

第一步當然是先問原來的購車的車商，看有沒有回購，或是認識的同行，可以報一個比較靠譜的收購價。這一點原車商的支援還滿重要的，除非自己有認識同行友人，畢竟買賣雙方是站在對立面，再怎麼哈拉套近乎，最後還是要在價格上兵戎相見，那原車商已經賺過你的錢，就比較能站在你的立場幫忙。

我的原車商也非常給力，先跟我科普了一下博弈雙方的立場，如果是好賣的車，車行的角度最主要是希望能收到車，雖然收價一定是越低越好，但真的能收到更重要，有點像是公司發你offer，搞了這麼久最主要還是希望你能來，有本事拿到competing offer的我就只好加給你不然你不會來，講到這裡突然發現很多事是相通的XD

另外網路因為方便，很容易就能問到價格，建議先製作一些制式的訊息，車圖片存google photo開共享，廣撒網，就是看有沒有機會問到更高，但也會有一些特別低的，像是X-20W之類的，這是正常的，因為有些車行不熟車種，不知道整理成本，也不知道怎麼出售，那當然就會抓保守一點，我們主要目的是要問到專精的，會整理也會賣的，那就願意出高價收。雖然報價不見得是收價，但會是合理的參考價，可以用來建立合理的story。

建立實底牌

有了價錢還不夠，因為網路報價都是X萬實際看車況，如果拿這個做competing offer，車商會說那是報高價騙你去的，現場看車況一定殺價，不準拉。

所以下一步是真的開車去一些車行現場估一下，找一些有做網路/youtuber的車商最好，因為這些店已經有投資在經營網路品牌了，會比較踏實做事，不然被搞個負評損失會比沒有經營網路的車行大很多，而且如果收價滿意，直接脫手節省時間成本也是OK，因為這些車行應該都不需要煩惱後續車況與過戶問題。

自己開車去估主要有兩個重點：

1. 取得真實車況與車價。中古車要挑毛病一定挑得出來，但重點是我們不知道那到底是小問題還是大問題。車商收車時，就有可能把問題挑一挑放大，然後說車況太差要整理要成本，不是汽修專業的我們就有可能被唬一唬覺得好像車況真的有大問題，別人收只會更低，趁早趕快賣了吧。
   先給人看車估價的話，至少會被挑出來的點都能先了解一下，有機會就回去跟車商對對看說詞有沒有合理，或者上網查一下。合理就給扣，不合理也要能辨別，並且理直氣壯的講回去。
   舉一些例子：
   a. 漏油還算正常，但這個年份里程漏成這樣我第一次看到，不是很合理，整理要2–3萬跑不掉，我們ㄧ定要整理過才能賣給客人。
   b. 你這看起來是雪地車，有很多鏽蝕，雪地冬天灑鹽，底盤會鏽比較嚴重，車漆也會比較容易被腐蝕。
   c. 有賽車椅嗎，有的話可以到X，沒有至少少10W。
   d. 有跑車排氣管嗎，沒有的話要再少1W。
   e. 紅色的皮椅買的時候是加價，賣的時候是減價。
   挑配備的話術，不用太信他，我建議一律都是找自己的優點回嘴，比如有自動跟車/大天窗/高級音響，配備滿哩程低之類的。
2. 建立真實感。開去估之前最好是能先把車子整理一下，像是能立即出售的樣子，因為車行也知道很多人只是來詢價，如果不是認真要出售的樣子他最後可能不會報給妳。

底牌還沒建立好時，容易心軟、恥力不夠的人最好不要答應約到府估車，因為讓對方白跑的虧欠感會在無形中影響你的決策。加上自己心中沒底，也就容易被一些看似專業的理由下砍心理防線，最後他們再營造車況這樣差，他們還願意這麼高已經很幫忙了，過村沒店囉。

實際例子：
車行說如果車況好可以直接上架也想X收，但是這個狀況我們真的沒辦法，最多只能X-10W。我就說沒關係不勉強我請你們吃個飯吧，他們就縮了轉回來問你多少可以，這就顯示他們很想收到車，此時應該合理範圍內報高不要害怕。

建立虛實並陳的故事

1. 讓車商覺得真的要賣，有機會收得到車，比如我工作異動要出國之類的，最好故事絕大部分都是真的，這樣聊天才不會有破綻。
2. 底牌要夠strong，挑不到毛病，才不會破價。比如原車商就算沒有回收車好了，但幫忙找業內朋友估一個不錯的價格，那我們也可以『包裝』成原車商的回估價，並且說都在原車商那保養車況他很熟悉了，沒有看車扣錢問題，這樣其他車行就很難找到理由把價格往下談，後續就可以說如果沒有比這高，那給原車商收就好了啊。

車況很好可以加價嗎？

收車時其實都沒在看你保養狀況，也不看維修紀錄，一般小擦傷的話也不會拿出來講，被問到有沒有待修時，我說門把燈不亮，車行都是說小問題就不追問了。我的感覺是一些小刮擦傷在中古車因為是常態，都不是大問題。反過來說，平時很追求完美，弄到一下就做局部烤漆，鋁圈刮到一點點就整顆修，最後賣車時是不太划算的。

也不用想先修好再賣價錢比較好，除非是引擎變速箱等不修會惡化的東西，我覺得主要是中古車都有標準收購範圍，再好的車，採購也不敢破頂上去收，在範圍內做事最安全。另外就是車行整理的費用肯定比消費者去修被賺一筆的費用低不少，這也是小問題他們不介意的原因吧。

如果是自售，那可能又是另一回事，我覺得自售買方的標準應該也會比較高，針對一些小問題就要更仔細來回談價，如果原本都整理得很好應該可以試試，但也要有應付一堆問問哥的心理準備。

中招套路分享

談定價格後就寫合約書，合約書一定要花時間一條一條慢慢看，最好在旁邊看他寫，不要聊天，就跟他們說你要專心看一下。像我其實是有看到全年稅費由我負擔，可是我車又不是用到年底，那後面不就是幫別人繳？這種先談完價格，再用埋藏在合約書中的細項陰回來的套路是屢見不顯。

類似招式我修鋁圈時也中過，先講鋁圈金額是X，真的換完結帳時說換一個輪胎工錢+1000元，最後變成X+1000，所以最好講價時都確認是『完工價』。

另外，最好能壓上一個過戶時間，越快越好，因為車輛過戶前稅款/罰單/停車費都還是原車主負責，就算合約有寫交車後車行負責，真的有問題時討錢一方都是弱勢。

為什麼要這樣無間道？

除了世道普遍是這樣以外，總的來說還是囚徒困境的單次博弈的問題，背叛的利益大於合作，但至少在多次博弈的職場，肯定不會，也不該這樣。

這次經驗我學到的是，針對單次博弈，要能在不同社會場合察覺並調整融入與環境相近的道德水準。

不過換個角度看，不想花太多心力搞五四三，降低道德水平會導致個人不舒適，時間成本太高的人，都可以給原車商，或挑網路有名的車商快速處理掉即可，差距沒有到很大。

矽谷為什麼？EP116 — S&P500上市公司高階主管的三階段管理哲學 挑戰美國職場天花板 | 專訪Etsy資訊長 謝居呈

內容講的都是比較典型的美式管理風格，我個人認為也是相對主流的風格。不過基於我個人在兩岸工作幾年的觀察，固定思維多少都存在，之前的主管怎麼帶怎麼教的，都是最真實的體感烙印，比起書上與training講的形而上，真實經歷更容易實操也更穩健，所以如果沒有特別刻意去思考和改變，大部份的人還是腳踏實地『遵循古法』了。

與其空泛地說怎樣比較好，不如比較一下差異在哪。本來我想把管理風格分成美式與中式，後來想了一下，用成長思維V.S.固定思維去解釋也滿順的，姑且美式就叫做成長型管理風格，中式叫做固定型管理風格吧。

首先，我認為產業與職務特性是影響管理風格很大的先決條件(無關職業優劣)，比如研發工程師 X 成長型管理風格，OK；產線作業員 X 成長型管理風格，也許不那麼適合。其中有一些本源的差異：

知識變化速率

軟體產業的知識變化速度極快，需要不斷更新知識因應變化。而變化本身使得不在實作第一線的管理者沒辦法擁有最up-to-date的知識做正確的決定，所以有一部分決策需要仰賴一線軟體工程師input，因此透明、合作來最大化正確決策的機率就是順理成章的事。另一方面，軟體發展的進程也不過是百年內的事，因此這個產業很多東西還在一直在高速發展中，比如之前大數據系統剛出來時，把大數據儲存與計算問題解決了，也使得需要大量數據運算的Deep Learning普及化，cloud/container/kubernetes讓software-defined infrastructure達到工業級水平而大爆發，這些也僅僅是近十幾年內在軟體產業發生的典範轉移，所以能不能跟上時代，持續學習成長的能力就很重要，在這個產業中如果不創新，就會被創新殺死。主管如果故步自封，拖累組織進化的進程，恐怕是要第一個被淘汰，或者讓組織『被淘汰』了。

反過來說，如果完成工作所需的知識幾乎固定不會變動，不需要員工提升組織的知識邊界，而是需要員工穩定、高效率、正確的輸出，那用成長型管理風格可能有點勉強。用固定型管理風格，主管獨立做決策快速給命令、員工遵從階級制度確保命令被貫徹執行，以恐懼建立威信，用嚴懲來嚇阻犯錯，可能相對適合。這裡講得比較極端，具體怎麼拿捏好度就是智慧了。

創新帶來的回報

軟體開發如果更多涉略研發與創新(不見得是research，新的應用、新的實作、新的business model都行)，有時也要一點運氣才能成功，但是軟體天性容易複製，網路效應容易放大成果，所以很容易scale，回報也就大， 因此就很適合有相對高一點的創新佔比。

訪談中提到創投如果看到一個創業家沒有失敗過的經驗甚至會有點擔心，因為他可能還沒撞過牆，還太過膨漲，不知道怎麼在邊界內做事。有經驗的創業老手知道怎麼take calculated risk，追求好的decision quality提升勝率，但也坦然接受不可控因素，從失敗中挖掘出有用的知識和以前沒考慮到的維度。

前面提到創新總有一點運氣成分，所以有良好的心態面對失敗就很重要。如果是固定型管理風格，管理者面對失敗就很容易敗給人性的弱點，會極力找各種理由，或用模糊的說詞避免直接承認失敗，因為害怕承認自己有所不足會有損自己的威信。這是因為擁有固定思維的主管覺得自己『應該要』比員工厲害，『應該可以』做好，所以有問題的話，一定是其他問題而不是自己有問題。有的主管則是自己都清楚狀況，但就是愛面子拉不下臉。

其實看破不說破，幫忙扶一下主管的面子，維持主管尊嚴確保指揮體系的效率，倒也無傷大雅，不過僅限在固定型工作環境比較適用。不承認失敗的另一面是放棄探究失敗的原因，對於知識相對固定的工作影響不大，但是如果是成長型工作，那所有人都錯失一次寶貴的學習經驗，軟體業impact scale大的天性，也可能令重複犯相同錯誤付出極高成本，更嚴重的是形成糟糕的表面文化。

這邊要注意的是，我們不是讚頌失敗，也要避免習慣失敗，或者用學習成長做藉口美化失敗。具體探究失敗的原因，保持成長心態，接受創新可能帶來的失敗，但如果是明顯可避免、工作態度不正確造成的失敗，也需作出適當的懲罰以設立底線，建立正確的價值觀。

市場供需

最後這個因素就比較現實了，優秀的軟體工程師一直都是都是供不應求，所以需要兩個面向來達成需求：

1. 培養：找不到人的一個方法就是自己養成，所以要採用成長型管理風格。
2. 留才：要留住人才就要有誘因，成長型管理風格能夠滿足人才自身的成長與成就感需求。

如果哪天軟體發展漸趨成熟，各種底層/中層/low-code solutions都齊備且能夠滿足80% of business requirements，也許軟體工程師的bargaining power就不存在了，到時候也只能忍氣吞聲求口飯吃，學習成長靠自己吧。不過我相信人類社會的發展一定是持續朝更好的方向前進，屆時大家都能擁有足夠的知識，判斷怎樣的管理方式適用。

最後

過與不及都不好，中庸之道的精妙在於了解整個系統後，如何妥善調控兩個極端中間的邊界來取得平衡。美國作家菲茲傑拉德（F. Scott Fitzgerald）在小說『了不起的蓋茨比』中說：『檢驗一流智力的標準，就是看你能不能在頭腦中同時存在兩種相反的想法，仍能維持正常行事的能力』。先不急著否定，探究事情的本源，也就能理解兩個截然不同的想法有各自背後存在的邏輯，往系統性理解前進一步。

走筆至此，大家應該不難發現我還不具備一流智力，文中多少帶有一些主觀傾向性吧(笑)。

裏頭有一段篇幅談到『識別知識的源頭』，大意是說，網路時代的各種文章充斥，很多文章的知識點不是原創而是轉譯過的，就像流言ㄧ樣，不同人的解讀與傳播到最後總是會失去原意。

比如大家都聽過的一萬小時定律，源頭是埃里克森與同事合著的論文『刻意練習在專業獲得的應用』，被格拉德威爾截取其中的一萬小時定律，寫成『異類』這本暢銷書而炎上。原作者埃里克森覺得自己的理念被誤讀，所以又出版一本『刻意練習』，強調沒有確定的時間門檻讓人成為大師，正確的練習才是重點。

我們生活中其實也有非常多例子，比如一些技術課程、Tech Talk、Blog，是的，你在讀的本篇文章前半段也是二手知識(笑)，不論是作者有意為之想發表自己的觀點，或是儲備知識不夠導致理解不到位，或是表達不清晰不能準確描述，或想做行銷，都有可能使得訊息不正確傳達，而形成不盡然正確的認知。

不過通常要探詢知識的源頭也並不容易，如果作者沒有留下線頭，本來就沒有這方面知識的讀者又怎麼知道要探尋什麼呢？

另一方面，知識的源頭有可能是well organized papers/books，但也有可能是比較散亂或不易閱讀的形式存在，比如討論串，程式碼，或非母語。這時候有人整理過的二手知識在效率上還是有很高的價值，所以二手知識並非不好，凡是現實的都是合理的，存在即價值。

我覺得二手知識只要把握兩點就能正確發揮其價值：

獨立思考

盡信書不如無書，書中他人分享的經驗知識肯定能增加自身的思考維度與深度，尤其新的維度是沒辦法憑空冒出來的，大家肯定有個經驗是不知道關鍵字所以沒辦法搜尋，這是『知道我知道，知道我不知道，不知道我不知道』中的最後一級。維度/深度增加了，綜合得出的結論就不會是每個人都一樣了，也許你讀過更多先進的思想，能總結出更高級的結論，但不論如何，讀的東西都有可能帶來收穫。

成長心態

我想除了數學這種能証明為真的學科以外，大概沒有什麼事能永遠是對的了。想想地心說與日心說，隔壁棚物理學，總是會有新的想法推翻之前的認知。所以即便是一手知識，也可能不盡然就是正確，但至少能反映當代人知識水平的最高殿堂，而新想法能取代舊的想法肯定是有其優越性在。讀二手知識也是一樣，我原本什麼都不知道，讀了一些，增維升級了，再往後讀到一手知識，就再升級上去，保持開放心態即可。

最後還是要頭尾呼應，講一下Open Source。

Open Source大部分先進的思想與技術都會先露出在社群之中，在Apache Way中更是規範things can be public must be public. 在資訊揭露上對contributors是極其友善的。任何人只要有300萬美金？阿不是，只要有網路就可以輕易的順藤摸瓜取得一手知識，差別在於是否有足夠的前備知識去看懂他們，此時一些品質好的二手知識就能有效作為中介橋樑。

大家應該也都有這樣的經驗，以前自信滿滿的自己，不聽建議而做了某些蠢事，等後來恍然大悟就覺得很丟臉，不過誰沒菜過呢？儘早接觸一手知識，儘早升級擺脫那個認知不全的自己，比起很久以後才明白，或者是永遠都不明白，都好多了。

同年11月，我離開了杭州回到台灣。

這是一份短命的工作經歷，但是關於中國，我覺得還是有不少經驗可以分享的。除此之外，我也會加入一些個人的思考，不一定正確，但我認為讀者一定都有能力對事物做更深層次的思考，不會照單全收。

這篇我會著重生活的部分，分幾個大項講：

租房

來到杭州第一個挑戰是租房，A公司這部分類似很多歐美大公司，待遇不錯，除了搬家費，也有一週的酒店住宿讓你找房。經我個人不詳實考究，搬家費與酒店都與同樣在中國的Microsoft還是差了一個檔次。

租房與台灣有幾點不同：

1. 沒有套房這種東西，除了家庭式3房以上(整租或分租)，就是酒店式公寓，大部分都是樓中樓(loft)。
2. 租金通常一次要先付3個月的份，簽約時還要多付一個月押金，所以第一次付款會很沈重，尤其是需要換匯的新住民。

如果想省仲介費，可以上58同城或一些刊登管道搜尋免仲介費的PO文，這些是業主直租的。

網路

翻牆是肯定要的，我個人常駐兩套方案，付費VPN和SSR。具體細節有很多專業文章在講，這邊就不展開。那為什麼要兩套？

1. 兩套可用性比較高，VPN哪天突然被封了也是很自然的。根據不準確的觀察，一些大節日付費VPN會不work，打客服也說沒辦法，原因可以自行想像，不過通常大節日VPN封掉SSR也難逃一死。
2. VPN和SSR都要client支持，而client不一定跨平台(筆電、手機、平板)，付費VPN當然什麼client都有，SSR client好一點的要買才有。
3. 有些網站VPN才能看到，SSR看不到，而且VPN可以選擇不同國家，碰到某些需要當地IP的場景有奇效(看劇)。

至於翻牆效果，我這麼解釋吧，就像洗澡一樣，還是有可能會洗到一半會沒水或是變冷水。通常晚上封包會大量丟失。所以總的來說，在中國翻牆工作還是挺傷生產力的，但也可以部分mitigate，比如搞搞cache，改連中國mirror等，這種就要根據工作內容去特化解法。

很多人會寄希望於公司有高速穩定的VPN，這個要具體分析，比如說有的公司是會限流，有的是設白名單，有的是拉整條專線接到日本等，quality差距會很大，所以最好還是先找在這家公司的人私下問問具體情況。

食物

A公司的食堂很棒，選擇多、便宜、美味。

外食的話，粗略計算大概是台灣消費的1.2倍。吃的東西差距不大，總的來說滿習慣的。有一些台灣沒有的，在杭州很夯的食物：小龍蝦、鱸魚、中式燒烤(醬的味道我很喜歡)。衛生是還OK，自己看起來都覺得怪的不要吃就了吧，比如在比較髒的馬路邊的燒烤。

外賣(餓了嗎、美團)便宜又方便，會經常使用。

娛樂

跟台灣一樣，逛街、唱歌、看電影、踩景點、看風景等。

電影比台灣便宜，尤其3D的便宜不少，3D眼鏡要買，但是很便宜，下次忘記帶也不心痛就買新的吧。台灣3D票價貴很多，眼鏡再怎麼消毒我還是不太想戴。

交通

短程打車、腳踏車、電動腳踏車是比較常用的，但是這種共享類型的交通要思考用槍時機，比如上下班時間，是否下雨都會影響，例如晚下班沒半台腳踏車可用，下雨打車要等50分鐘。公車也很多，但是要注意營運時間，有的只運行到7、8點。

較遠一點的移動會搭配高鐵、地鐵、巴士，基本上大眾交通票價都滿便宜的。注意高鐵用台胞證訂票有諸多不便，要現場取票，排隊會排很久，經常有人説趕不上了要插隊等。

人

恩，很敏感的話題…

可以分兩塊來講，公司內的人都是很好溝通的，和人交流和台灣沒太大區別，我和一起培訓兩週的小夥伴們建立了非常深厚的情誼，曾一起兩天一夜遊歷黃山，甚至我離職後有機會再去到上海，還特別坐了動車去杭州和的大家一起遊千島湖。我想是因為A公司的文化有點類似苦行僧，小夥伴們聚在一起時總能有話題和共鳴吧。

而面對一般大眾，有些事情會需要寬心，重申一下，都是比例問題：

1. 插隊：
   換個角度思考可能比較舒心(?)，自由競爭，搶到算你厲害，搶輸算我技不如人，也是一種遊戲規則，只是我們習慣另一套排隊的規則。不論如何我是排隊派的，如果卡位厲害就能搶贏上車進電梯，那反過來也是歧視一些弱勢的群體，欠考慮了。與此同時，中國也很努力在做教育，宣導文明排隊，只是教育需要以世代為單位的時間。
2. 說話音量：
   講話很大聲，大聲放影片，都是滿正常的日常遭遇，台灣當然也都有，機率小一點。
3. 肢體接觸：感覺personal space是比較小的，比如排隊，總是會被後面的人或多或少touch到或推擠到，完全不是我覺得舒適的人與人之間距離，我不知道後面的人是不是下意識覺得往前擠可以加快排隊速度？？？
4. 互信：
   我直接分享一些經驗吧：
   (a). 吃飯問店家說要開發票可以嗎，回答OK我們才進去吃，之後說發票用完了下次找他拿，下次登門說還沒補發票下次再來，就這樣跑了3+次，每次都有理由，最後才開到發票，幸好這家店在我回家的半路上…
   (b). 到上海出遊一樣吃飯問發票說OK，結帳時說留地址幫我寄過去，就這樣了無音訊，微信問幾次無下文，美團負評才主動私訊我講很多經營困難的話討同情…
   總的來說都能感覺到店家不老實，當然也是有很多店家很誠實，有一家拉麵店真的事後寄發票給我，花了不少運費，很良心。
5. 道德：
   舉個實例，辦公室突然跑來一個人急著充電，想要拿走隔壁同事的充電器，同事人不在，我上去跟他說要問主人借才行，他說沒差吧。我不知道這是因為文化價值觀上比較傾向共有的觀念嗎？
6. 政治：
   小區的警衛找我閒聊知道我是台灣來的，會很自然而驕傲地說你看我們祖國很棒吧。

總的來說，我覺得這是一段很有價值的經驗，經驗就是從實務中體會那些難以言喻的不同點在哪，有了對比，就能型成一個有變量的維度，而不斷增加看事情的維度就是認知升維的過程。

如果要我對這段經歷下一段註解，我會說我認識了很棒的朋友，經歷過難忘的時光，挑戰過很有趣的工作：）

同事排查問題後，發現是運行在python UDF的ML code有memory leak導致OOM。其實把memory leak的問題解決作業就恢復正常了，不過既然原本就有memory leak，那為什麼在Spark 2時沒有問題，升級Spark 3後才出現呢？

Open Source的一大優勢就是程式碼(result)與開發過程(reason)全部公開透明，所以可以一路往上追root cause。帶著這個問題，我們嘗試往下找答案。

首先透過Spark UI觀察成功與失敗作業有什麼不同，發現失敗作業的# tasks明顯比較少(個位數或十位數，遠少於default 200)。再觀察# records per task：# tasks少的作業，# records per task就多。看到這裡不難發現# tasks (or # partitions)有被動態調整的跡象，如果再搭配對Spark 3剛上市的Adaptive Query Execution(AQE)有所了解，就不難推測出可能是Dynamically Coalesce Shuffle Partitions造成的。

具體的推測是這樣：

Dynamic Coalesce把# partitions調整得太小，單一partition資料量太多，使得單一task產生的memory leak超過container上限，引發OOM。

但還有一個問題是，為什麼跑相同input data，結果卻是non-deterministic的呢(# tasks不一樣)， coalesce應該是根據partition的size計算合併結果，同樣的input data應該有同樣的結果才是。

翻閱Dynamic Coalesce的文件，找到可能有兩個參數影響合併結果：

spark.sql.adaptive.advisoryPartitionSizeInBytes
spark.sql.adaptive.coalescePartitions.minPartitionNum

經測試advisoryPartitionSizeInBytes應該不是原因，所以往minPartitionNum方向查。我們可以從SPARK-31124了解到minPartitionNum的預設值設計理念，基本上是說如果cluster已經allocate X cores了，那我們就應該讓parallelism(# partitions)至少等於X，才能充分利用所有cores而不會有資源閒置。

我們並沒有主動設定這個參數，根據minPartitionNum的說明，發現其中the default value is the default parallelism of the Spark cluster這段說明應該是關鍵：

The minimum number of shuffle partitions after coalescing. If not set, the default value is the default parallelism of the Spark cluster. This configuration only has an effect when spark.sql.adaptive.enabled and spark.sql.adaptive.coalescePartitions.enabled are both enabled.

不過這個default parallelism是怎麼決定的呢，文件說得比較籠統，所以透過trace code來確定具體是哪個值，先找到minPartitionNum是如何設定的：

val minPartitionNum = conf.getConf(SQLConf.COALESCE_PARTITIONS_MIN_PARTITION_NUM)
          .getOrElse(session.sparkContext.defaultParallelism)

Reference

找到是從sparkContext.defaultParallelism取值，而sparkContext.defaultParallelism是這樣設定的：

override def defaultParallelism(): Int = {
    conf.getInt("spark.default.parallelism", math.max(totalCoreCount.get(), 2))
  }

Reference

至此我們找到具體參數是spark.default.parallelism，如果沒有顯式指定就是取cluster的core數作為defaultParallelism。cluster的core數可以通過submit job時指定num-executors和executor-cores決定，但另一個動態優化的功能在這裡發揮了巨大的影響，也就是Dynamic Allocation。

由於Dynamic Allocation會動態增減executors數量，再加上YARN allocate containers(executors)的時間與結果是會根據cluster available resource而有所變化，最終導致了Dynamic Coalesce出現了non-deterministic的結果。透過開關Dynamic Allocation和調整Dynamic Allocation參數跑測試，就可以驗證這件事。

重新整理一下整個脈絡：

1. 執行python UDF時，Dynamic Coalesce根據advisoryPartitionSizeInBytes以及minPartitionNum決定要合併成多少個partitions，又，因為python UDF運行的是CPU intensive的ML task而非data intensive的data processing task， 單一partition資料量遠小於advisoryPartitionSizeInBytes，故Dynamic Coalesce傾向盡量合併partitions至最低不小於minPartitionNum 。
2. Dynamic Allocation因為cluster繁忙狀況不一取得不定量的executors，# executors * # cores = totalCoreCount (defaultParallelism)
3. 當Dynamic Allocation取得的executors數量較少時，minPartitionNum=defaultParallelism數字小，Dynamic Coalesce合併成小量partitions，此時單一partition的# records大，加上UDF中有memory leak導致使memory使用超過container上限被YARN OOM killed。

最後，minPartitionNum在Spark 3.2.0後已經被deprecated，根據最新文件表示，在3.2.0後主要就是看minPartitionSize，預設1MB

spark.sql.adaptive.coalescePartitions.minPartitionSize

並增加一個parallelism優先的參數，預設是true

spark.sql.adaptive.coalescePartitions.parallelismFirst

有興趣的可以參考SPARK-35968。

原本的設計是advisoryPartitionSizeInBytes預設64MB，也就是比較aggressive的合併，再透過minPartitionNum保障基本的parallelism，可以看作是合併優先策略。

回歸Dynamic Coalesce的本質，確實是有size特別小的partition再合併就好，minPartitionNum有點像是把參數的調控範圍延伸到整個作業範圍的# partitions，包含size正常不需調整和太小需合併的partitions。按照新的設計，3.2.0以後應該就不會碰到本文的狀況了。

NoSQL也是可以有SQL介面的，Apache Phoenix / Casandra CQL / MongoDB query language是一些例子，不過SQL提供的強大功能如aggregate / join在NoSQL上因為data partitioning的關係所以不完全支持，即便支持也因為效能問題需要謹慎使用，所以SQL+optimizer帶來的優勢不是很大(在OLAP系統中反而非常吃重)，比較多的還是提升易用性。但SQL+optimizer是運行在CPU+Memory+小量metadata的環境高速迭代，針對database這種read/write against disk的場景來說，SQL對性能能起多大決定性作用，我是打問號的。

換個角度來看，NoSQL通常以high write throughput為主打，因為寫時主要是append write ahead log和mem table就完成了，但相對讀時要做的事情就比較多了，需要讀取mem table和掃on disk的SS tables來整理出需要的rows和versions。比起維護單一version的B-tree database來說，NoSQL不見得比較快。另外NoSQL在flush mem store和運行compaction時帶來的性能影響也不若B-tree database這麼省心。

不過講者說的另一段話是沒錯，那就是B-tree database因為是二元樹形式，因此只能在一定的量級內提供能良好效能，而NoSQL有比較好的scalibility。

NoSQL不論是Range或是Hash Partitioning的實作，都能利用key和partitions的mapping關係，排除大量無效的搜索空間，而且這個操作幾乎與資料量N無關；B-tree要locate到row則需要LogN的時間，比較容易受資料量影響效能。

總的來說，我不會說NoSQL就比較快，它們有各自的強項such as NoSQL has better scalability; B-tree database has better support over ACID. 縱然有如Spanner這類NoSQL(or NewSQL)利用原子鐘等特殊硬體打破網路不確定性的限制做到distributed transactions，在NoSQL上達成ACID需要更高的成本(特殊硬體、等待延遲、運算量)是不變的。