《一擊必中的狙擊手法則》:狙擊手思維與其說是天生擁有,不如說是後天造就

《一擊必中的狙擊手法則》:狙擊手思維與其說是天生擁有,不如說是後天造就
Photo Credit: leninscape@Pixabay CC0

我們想讓你知道的是

卓越不是人們與生俱來的特質,必須添加十幾種成分才製造得出來,當中的關鍵就是古希臘德爾菲神諭說的「了解自己」,創造你的核心。

根據正向心理學,心流(亦稱「化境」)是工作時的心理狀態,執行特定工作的人徹底沉浸在工作當中,察覺不到干擾因素的存在,因此無從阻止他們達到顛峰效能。亞洲地區有傳統的靜觀與禪思文化,因此有大量的文學作品描述這種近乎神祕的心理狀態。在佛教與道教的教義中,也都提及「無為而治」的心智狀態,很類似心流的概念。印度教經文講述的不二一元論(例如《王者啟明之歌》),和瑜珈知識(例如《博伽梵歌》)指的都是類似的狀態。

然而,心流的感覺其實不神祕。匈牙利的米哈里.齊克森米哈里(Mihaly Csikszentmi- halyi)是心流心理學的先驅,目前是克萊蒙研究大學的心理學管理教授,他曾在芝加哥大學心理學系與森林湖學院社會人類學系擔任系主任,研究重心是在職場上協助使用心流。

齊克森米哈里長期研究那些看似神祕的現象,訪談對象有音樂家、舞者、作曲家、武術家、畫家、作家、企業家與商業領袖。這些人在高壓下工作時,大腦的運作達到相當驚人的同步化,還能在多種不同的優先事項之間切換。

齊克森米哈里想要了解箇中原因,於是他與同事合作,訪談世界各地八千多人,再把這些人的經驗彙總起來。受訪者形形色色,有多明尼加的僧侶、盲眼修女、印第安納瓦霍族的牧羊人、矽谷的高階主管等等。

為了解釋心流發生時所依循的機制,他發展出一套以「人類頻寬」為中心的理論。在一個由資料組成的世界裡,每件事都是資訊。生物學施加的位元傳輸率限制,塑造出終極閘道。大腦處理資訊的能力高低,左右了我們理解的程度。

我們是由一堆感測器組成的複雜網路所構成,大腦和身體組成不可分割的網路,並沿著這網路捕捉資訊、傳輸資訊。至於人腦處理資訊的方式有各種解讀,同時也是神經學領域激烈爭論的主題。在這場爭論的另一端,則是那些認為大腦像電腦那樣運作的人。那些人的主張為:

大腦有如大規模平行處理器,以重疊型的神經元連結模式存放資訊。單一神經元能參與多種不同的記憶與過程。所以人腦才會如此善於辨識樣態,才會因為一個想法或記憶,就能讓人想到另一個想法或記憶;才會一個氣味就能觸發記憶如洪水般湧來。

另一方面,有少數人認為大腦是感測器網路密不可分的一部分,造就出今日的我們:

以下是我們天生沒有的東西:資訊、資料、規則、軟體、知識、語彙、表述、演算法、程式、模型、記憶、影像、處理器、子程式、編碼器、解碼器、符號、緩衝區。這些設計元素可讓數位電腦的行為變得智慧些。但我們不僅天生沒有這類東西,也不會發展出這些東西,永遠不可能。

兩大陣營之間的爭論最後結果如何,或許取決於長生不死的訣竅,又或者是取決於以下問題的答案:「人類應不應該創造出終有一天會超越人類的超級智慧機器?」「人類能不能學會把意識下載到某種儲存裝置裡並永遠活著?」

儘管雙方針對大腦運作方式所提出的理論相互扞格,卻在一件事上面產生共識─大腦在處理資訊流時,隨機存取記憶體(Random Access Memory,簡稱RAM)及其受到的生理限制。二○○四年齊克森米哈里在TED發表演講,說大腦能處理的資訊上限是每秒一百一十位元。看起來雖然很多,可是分配給一天當中任何一刻必須要做的各種事情,就顯得不夠用了。

舉例來說,對話是複雜的多層次程式碼,每秒要耗掉六十位元,才能跟上對話的速度,所以我們跟別人講話時,才會無法全神貫注在別的事情上。在大部分的情況下,我們能決定注意力要放在哪些事情上,通常也能一心多用,將大腦的頻寬容量分配給多件事情。

然而處於心流狀態時,大腦全神貫注在一件事情上面,而且不是有意識地決定要做。於是個體察覺不到其他的事情,例如時間、人、干擾因素,甚至忽略基本生理需求。這種現象之所以發生,是因為處於心流狀態的人,把注意力全都放在手邊的事情上,沒辦法分心再做別的事情。

由此可見,就思維能力而言,狙擊手的思維不一定比別人優越,只是在受過訓練的事情上較為優越。換句話說,為了達到最理想的表現狀態,因此可以忽略其他事情,只專注處理手邊的工作。很顯然地,狙擊手思維與其說是天生擁有,不如說是後天造就。如果是後天造就,就表示我們也全都能運用類似的心理優化技巧,學會更好的思維模式。

相關書摘 ►《一擊必中的狙擊手法則》:狙擊手全都使用兩個相同的觸發詞語來激發心理意象

書籍介紹

《一擊必中的狙擊手法則:商場如戰場,學習狙擊手思維,用最少資源達成不可能的任務》,核果文化出版
.透過以上連結購書,《關鍵評論網》由此所得將全數捐贈兒福聯盟

作者:大衛.艾莫蘭
譯者:姚怡平

商場即戰場,培養適應局勢的全能素質,在高度壓力下發揮超凡水準,一出手,就是要贏!

戰場上狀況總是詭蹫多變,即使是平淡無奇的白日也可能突然變成夢魘一場。而商場就像戰場,同樣多變且富挑戰性,我們必須具備高超的執行力,才能符合需求,達成專案目標。

訓練精良的狙擊手,擁有淬練過的強健心智,是全方位的菁英。若能學習狙擊手思維,運用在工作上,不論是面對突發狀況不斷的專案,或是必須迅速做出艱難的決策,都能展現堅毅的超凡素質。

本書以狙擊手與美國海豹部隊為背景實例,透過分析先進的軍事訓練技術和尖端神經科學,以條列式說明及內容歸納,教導讀者如何將狙擊手法則化為具體策略和真實技術,落實在工作與生活中。

一擊必中的狙擊手法則_立體書1
Photo Credit:核果文化

責任編輯:朱家儀
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡