有些人會在一年之初立志「今年要讀一百本書」,真是無聊透頂

有些人會在一年之初立志「今年要讀一百本書」,真是無聊透頂
Photo Credit: Depositephotos

我們想讓你知道的是

我並不認為自己讀了兩萬本書有多了不起,讀書真正了不起的地方在於「有沒有發揮功用」。透過書本獲得新知,在商場上發揮出來,對社會做出貢獻,才能讓我感到快樂。讀書的重點在於「目的」而不是「數量」。

文:土井英司

不懂的事本來就該慢讀

當我提到自己每天讀三本書,一定會有人問我:「花多少時間讀完一本書?」這要看書本的厚度,但通常我只花二十分鐘。此時提問的人都會驚呼:「好快!你是用什麼速讀招數才會這麼快?」

其實我沒學過什麼速讀,而且不覺得速讀有什麼特別的好處。因為能不能速讀,與讀書品質的好壞,是沒什麼關聯性的。

相反地,我認為書應該要讀得慢,讀得仔細。

我讀書這麼快其實有個契機,在希臘留學的時候曾經有份作業,就是要讀完兩百五十頁的英文書,寫出一份篇幅高達十頁A4紙的報告。這個內容已經不簡單了,更可怕的是老師傍晚出作業,隔天上午就要交。

當時我想,完蛋了,這絕對不可能。但時間緊迫不做不行,只能焦急地翻開英文書。此時直覺突然告訴我,這兩百五十頁之中哪些該讀,哪些可以跳過。連我自己都被自己有此能力嚇了一跳。仔細想想,其實道理很簡單,因為報告有訂出主題,只要找出與主題相關的部分仔細閱讀即可。

也就是說,只要有明確的「目標」,你讀書的品質與時間都會改變。目標之外的資訊都不需要花時間讀,速度當然會更快。

假設你要讀杜拉克的《管理學》,「目標」是了解身為領導人該怎麼管理下屬,那麼只要讀相關部分就好。看看書本的簡介與目錄,搞清楚你要學什麼,仔細鑽研這些部分就好。「快」只是一個結果,本身毫無價值。

但我想還是有人希望能讀書讀得更快,請聽我一句勸。

所有的書你都讀不快嗎?

應該有些書讀得快,有些讀得慢。

想必你有擅長與不擅長的內容。讀到不擅長或不熟悉的內容,讀得慢是理所當然,因為你不懂,慢慢讀才會懂,才會理解,才會吸收。這段過程是何等愉悅?由「不知」邁向「知之」是一件大工程,千萬不要把它想得像微波爐熱菜一樣簡單。

慢慢讀,好好懂,懂得愈深,讀書速度自然就愈快。

以「今年要讀幾本書」為目標實在太遜了

前面提到「讀得快」沒價值,同樣地,「讀多少本」也沒價值。我並不認為自己讀了兩萬本書有多了不起,讀書真正了不起的地方在於「有沒有發揮功用」。透過書本獲得新知,在商場上發揮出來,對社會做出貢獻,才能讓我感到快樂。

有些人會在一年之初立志「今年要讀一百本書」,真是無聊透頂。讀書的重點在於「目的」而不是「數量」,所以應該立志的是你的「目的」。有時候讀了十本書,不如把一本經典讀十次,因為真正的好書,可以讓你依據十個不同的目的,反覆讀個十遍。

  • 如何提升幹勁?
  • 如何建立正確的人事制度?
  • 如何打造暢銷產品?
  • 如何正確管帳?

只要內心湧上疑問,就重讀一次。

讀一堆不同主題的書是很有趣,但若想在有限時間內吸收學問,這麼做的效率就不高。要在短時間內鑽研特定主題,就不需在意讀多少本,而是應該掌握重點深入學習,這樣才能更快達到目標。如果能讀完單一主題的三十本書,應該算得上是專家了。

另外,鎖定主題深入研究,過程中也會接觸到相關的其他主題,並很自然地引發研究其他主題的動力。因此請不要隨機亂讀,先鎖定一個主題,然後依循相關主題接連閱讀,這種開枝散葉的讀法,更能有機地逐步吸收,增加自己的學養。

你的閱讀是「喘息」或「努力」?

讀書對一流商務人士並非閒暇之餘的樂事,而是做生意的「起點」。為了目標而讀,獲得新的知識與見解後,展開新的行動。

有些「旅遊愛好者」每年都會出遠門放鬆個幾次,但這樣不能變成旅遊專家,真正的專家必須掌握怎麼買票、當地有哪些美食、不同的旅館分別有哪些服務、通往景點的祕徑、捷徑等一切資訊。必須成天只想著旅遊,想著怎麼提供大眾更多有益的資訊,這種「一流的變態」,才能成為專家。

讀書也是一樣,專家整天想著管理、領導、行銷、金融,不斷挑戰自我,所以讀書是專家用來解決問題的最佳工具。今天拿紅筆在醍醐灌頂的一段字句上畫線,明天就付諸行動。

所以讀書是「努力」,絕對不是「喘息」。

如果讀書有分「積極」與「消極」,我當然推薦「積極」讀書。

但若真的是精疲力竭,選本輕鬆簡單的書來喘口氣,為自己充個電也不錯。

不斷往前衝、往前衝,偶而停下腳步休息,或許是不錯的閱讀步調,畢竟受傷了還是需要時間調養的。

半途受挫是最棒的,請珍惜你的「不知」

「讀書讀到一半就受挫。」我想你應該有這種經驗,而且多半把它當成一件負面的事。但讀書受挫其實是美事一樁,這有兩個原因。

第一,至少你在受挫之前,都是認真面對、主動地挑戰這本書。

當你在書中讀到新知識、未曾實踐過的技術,會覺得很難理解,造成心理負擔,因此才會半途放棄。

這種「主動」的思考方式,就是閱讀的一大優點。

引人入勝的影集或電影,不需要觀眾花心力去懂,劇情依然行雲流水地推進。如今大多數的電影都老少咸宜,適合闔家觀賞,所以很好懂,觀眾完全處於「被動」接受的狀態。

但書本,尤其是商業書,必須經過思考消化才能讀下去,是主動的行為。

閱讀,思考,決定要不要接受,然後繼續閱讀與思考。長久下來,你的思考能力會更加成熟。而不需要動腦筋就能懂的書,讀起來或許暢快,卻無法鍛鍊你的大腦。

「半途受挫」代表這本書對現在的你來說負擔太重。比方說經典作品,或者與自己興趣不同的領域,讀起來經常令人受挫,但你應該抬頭挺胸,相信自己讀這些書是很棒的挑戰。

挫折還有另外一個好處。

當你讀書讀到受挫,代表你已清楚發現自己「不懂」的地方。例如「我讀一本知名作家的名著,讀到第幾章第幾頁,其中有個地方就是不懂。」在這不懂的地方畫條線吧,這條線將改變你的人生。


猜你喜歡


挖掘雲端開放架構優勢!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。

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


猜你喜歡