如何得到一份像我這樣的工作?(下)

我給的三點建議:1. 保持好奇心、廣泛地閱讀、嘗試新事物。2. 接納一切事物。3. 假設其實沒有人知道自己在幹嘛。
評論
評論

本文為 〈 如何得到一份像我這樣的工作?(上) 〉 續篇。

第四步:創建(Build)

後來我放下這些去史丹佛讀了一年大學,那是加州一間有如田園詩般的小學校,陽光永遠是那麼閃耀、草地永遠是那麼地綠、學生總是往外跑。那裡有一些很棒的教授,我也的確學到很多,但我感受不到知性的氣氛,因為大多數的學生似乎一點也不在乎學習和研究。

但是在接近年底的時候,我收到一封署名「Paul Graham」的信,他說自己正要開始一項「Y Combinator」計畫。背後的概念是找一群聰明無比的程式設計師,將他們聚在一起、給他們一些錢、完成一切文書作業後成立新公司。這群人在打造新公司/服務的同時,也很用心地學習 Y Combinator 教的一些必要知識,例如商學、如何找投資人或買主等等。Paul 建議我提出申請加入 Y Combinator。

於是我照做,也入選了。在長時間辛勞地工作後,我發現自己正在做一個叫「Reddit.com」的小網站。其實我們根本不知道自己在幹嘛,我們沒有任何商業方面的經驗,我們真正打造一個產品的經驗也不多,甚至我們也不知道自己的網站到底行不行,或是為何可行。每天早上我們起來就是確認伺服器沒有掛點、網站沒有被垃圾留言給佔領、使用者也沒有棄我們而去。

當我剛開始做 Reddit 的時候,成長得很慢。這個網站很早就上線了,我們只用了幾週就做好。前三個月裡,每天超過三千人造訪已屬難得,也差不多就是一個 RSS feed 的基本水準。後來,過了幾個禮拜馬拉松式的 coding,我們將 Reddit 從 Lisp 語言換成 Python,我也因此在部落格寫了一篇文章。這件事受到許多人注意,沒有人生氣起來像 Lisp 粉絲那麼誇張。直到今天,我在派對上自我介紹時提到自己在 Reddit 工作,人們還是會說:「噢,是那個從 Lisp 轉換出去的網站。」

差不多就是那個時候,網站的流量開始起來了。之後的三個月,我們的網站流量翻倍了兩次。每天早上我們都會查看一下流量圖表、看看我們表現得如何——加入的新功能是否獲得關注、我們的網站是否在網友間口耳相傳、使用者有沒有拋棄我們等等。每一天數字都成長得更高。每當我們稍稍從工作中休息一下、喘口氣,網站看起來還是成長得一天比一天快。

但我們還是不知道要怎麼賺錢。我們在網站上賣 T-Shirt,但是每當我們賺了一點錢,也只能用來訂更多 T-Shirt 來賣。我們也開始賣廣告,然而表現得並不好,差不多就是每個月幾塊錢。我們也想過授權「Reddit 技術」給其他像我們一樣運作的網站,卻找不到誰真的需要這種授權。

很快地,Reddit 每個月都有數百萬的使用者造訪——一個遠超過美國一般雜誌讀者的數字,我會知道是因為當時跟很多雜誌發行商聊過,他們都很好奇 Reddit 的魔法是否也適用在他們身上。一開始,我們對他們建議的每件事都說好,而且很幸運地,也都管用,因為我們寫程式的速度比他們寫一份正式合約的速度還快。

此外,線上新聞網站也開始注意到 Reddit 能為他們帶來巨大的流量。他們覺得在所有文章加上某種「Reddit this」的連結可以帶來更多流量。但是據我所知,加入這種連結其實對文章在 Reddit 更受歡迎其實幫助有限(而且還會讓你的網站看起來更醜),不過這的確是幫我們打了許多免費的廣告。

沒多久,談合作就變成談收購。被收購——我們一直以來的夢想!再也不必煩惱網站賺不賺錢。有些公司願意接手這件事,我們還會因此致富。於是我們放下手邊所有的事務進行協商,然後那些工作就一直被晾在一旁。

我們花了好幾個月協商。首先,我們對價格爭論不休。我們準備了一堆計畫跟報表,到他們公司總部做簡報、參加永無止境的會議、講一大堆電話。最後對方回絕我們的報價,我們就這樣走了。後來他們的態度改變,我們還是握手同意了交易,開始商討一些關鍵的部份,然後談判又破裂。最終定案前我們這樣來回了大概三、四次,還因此停下手邊的工作長達半年之久。

我開始必須瘋狂地考慮金錢問題。因為壓力的關係,我們開始變得很敏感、缺乏生產力。我們開始互相吼叫、冷戰,接著再設法回頭一起工作,然後又開始彼此互相大吼。在收購定案前,這家公司幾乎要分崩離析。

最後,我們跟律師一起簽完了所有文件,隔天錢就進了戶頭,結束了。

我們全部移到舊金山,開始到 Wired News(我們被 Condé Nast 這家擁有 WIRED 等多本刊物的巨型出版公司收購)辦公室上班。

那時我蠻慘的,我難以忍受舊金山、難以忍受辦公室的生活、難以忍受 WIRED。我生病了,過了一段很長的聖誕假期,也想過自殺,跑給警察追…… 當我禮拜一早上回到辦公室,他們叫我辭職。

第五步:自由

失業的前幾週感覺蠻怪的。多虧舊金山的陽光,我在家附近閒晃,也讀了很多書,但沒多久我就發現自己需要做點事。我開始寫書、開始整理我在心理學領域發現的有趣研究,我不是要談那些研究結果,而是用說故事的方式。每天我都去史丹佛大學的圖書館(史丹佛大學對心理學家來講是所好學校)。

但有一天我接到 Brewster Kahle 的電話,他創辦了 Internet Archive,一個意圖將所有東西數位化之後放上網路的超酷組織。他說他想要將我們過去聊過的計畫付諸實現。那個點子就是收集世界上所有書裡的資訊然後將之共同存放在一個地方,一個自由的維基系統(a free wiki)。

譯註:這裡的「維基」指的是網路上開放且可供多人協同創作的超文字(hypertext)系統。

於是接下來幾個禮拜我投入了這個我稱之為「圖書館」的工作,號召程式設計師、與一位設計師合作,並且做了其他奇奇怪怪的工作,就為了讓網站上線。最終這個網站成了「開放式圖書館(Open Library)」(openlibrary.org)。這個網站很多部分的工作是由一位非常優秀的印度程式設計師完成:Anand Chitipothu。

另一位朋友 Seth Roberts 建議我試著去改善高等教育系統。雖然對於解決方案我們無法達成共識,但我們一致同意一個好辦法:一個告訴學生不同職業之間差異為何的維基系統。這個網站就快上線了。

另一位老朋友 Simon Carstensen 寄來一封 E-mail 說他從大學畢業了,打算找我創辦一家公司。Well,一直以來我都有份創業點子的清單,於是我就把排行第一的點子拿來用:讓架設網站變得跟填一個文字輸入框一樣簡單。接下來幾個月我們不斷努力讓網站變得越來越簡單(同時也變得比較複雜)。這個網站最近上線了,叫 Jottit.com。

同時我還申請擔任兩個暑期程式計畫的「導師(mentor)」,這兩個計畫都極富野心而且相當驚人,也就快上線了。

我也決定要投入新聞工作,第一篇文章已經刊登出來。我弄了幾個跟科學有關部落格,開始著手進行我自己的學術論文,這是基於我自己對「誰才是真正寫維基百科的人」此一議題的研究。有一些人,包括 Jimmy Wales(維基百科創辦人)這位維基百科發言人,都聲稱維基百科並非是個大型的分散式計畫,差不多就是 500 人左右在貢獻內容,許多人還是他也認識的。他是做了一點研究支持自己的論點,但我在處理數字上面更加小心,也發現截然不同的結果:維基百科上有非常大量的內容是來自於新的編輯者,許多人甚至還沒有申請帳號,只是在條目中東加一句西加一句。為何 Jimmy Wales 會犯下這個錯誤?因為他看的是每一個使用者做出更改的次數,卻沒有觀察到他們所更改的「量」有多大,所以這 500 多人對維基百科做了非常非常多的編輯工作,但他們每一次編輯所修改的內容都很少,大多只是修改拼字錯誤、更改格式等等。所以我們似乎更有理由相信這 500 人是在「編輯」維基百科而非認為他們是在「撰寫」維基百科。

我的建議

所以秘訣是什麼?我如何用簡潔的幾句話就說完做過的事,讓自己聽起來像是個還不賴的人?

保持好奇心、廣泛地閱讀、嘗試新事物。 我想許多人們所說的智慧,追根究柢都是源自好奇心。

接納一切事物。 我很不擅長說「不」——到了病態的程度,無論是計畫、訪談邀約或是對朋友。我做過非常多的嘗試,即便當中大部分都是失敗的,我還是有所作為。

假設其實沒有人知道自己在幹嘛。 有一大票人拒絕嘗試,因為他們覺得自己知道的不夠多,或是他們假設自己所想到的所有方法其他人一定已經全都試過了。Well,的確有一小搓人真的知道該怎麼把事情做對,而知道要嘗試新事物的人又更少。所以如果你願意在某些事上全力以赴,想信你會做得不錯。

遵循這些法則造就了今日的我,一大堆專案讓我壓力沖天。

每天早上我起來收信,查看有哪個計畫今天會崩盤、有哪個最後期限得趕上、有哪個演講需要準備、有哪篇文章我得編輯……

或許,有天你也會像我一樣,萬一果真如此,希望我能幫上忙。(全文完)

本文的作者相信大家都猜到了,他是 Aaron Swartz。這樣一位年輕才華洋溢的人, 卻在上週以年僅 26 歲之齡,於紐約家中自殺了 ,令人不勝唏噓。


開發者享受 CI/CD 價值!運用 Amazon EKS 整合 GitLab 創建自動化部署

企業如何在 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 部可以獲得以下三大好處。

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

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。

了解 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。

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