「為什麼要有求職天眼通?」以及這一年我在求職天眼通的工作體驗

去年我寫了「求職天眼通」來讓大家寫下公司和工作的評價,後來也成立公司來專心做這件事情,現在差不多一年了,是該寫一篇關於在這個公司工作的評價。
評論
Photo Credit:原圖來自愛奇藝經本篇原文作者後製
評論

本篇原文刊登於「求職天眼通」創辦人 Denny Ku 之 medium 與求職天眼通 部落格 ,INSIDE 獲授權後轉載。關於 Denny:是 Denny,不是 Danny,de for debug。 求職天眼通的作者。 正在努力學習如何成為一位專業的軟體工程師,以及發揮影響力,把話語權從奇怪的人身上拿回來。

去年我寫了「求職天眼通」來讓大家寫下公司和工作的評價,後來也成立公司來專心做這件事情,現在差不多一年了,是該寫一篇關於在這個公司工作的評價。

世界上只有一種真正的英雄主義,就是在認清生活真相之後仍然熱愛生活。 — — 羅曼羅蘭

這是在準備大學指考時背下來的一句格言,沒想到現在剛好可以幫這個有點太精彩的一年下個註解。 這一年掉了很多頭髮,也理解到壓力很大胃真的會很痛,希望可以藉由這個機會分享給各位我這一年學習到的事情。

1. Hi 大家,我是 Denny 

從寫出「求職天眼通」到現在,已經一年了,覺得該跟支持和反對我們的人說聲謝謝,還有身邊的人說聲辛苦了。勞動環境的問題平常在粉專上小編已經講了很多,現在不如讓我講講在「求職天眼通」這個位置上到底看見什麼事情。

2. 為什麼該有「求職天眼通」

先從自己為什麼要加入這間公司說起,「求職天眼通」一開始是個讓大家能在各個工作頁面底下留下評論的插件,現在,不只針對工作,也是個能對公司留下評論的網站。為什麼這東西需要存在?

從求職者的角度來看,找工作前最需要的就是蒐集情報,來看看有哪些管道:台灣的 Linkedin 大部分都是獵頭在上面找人,在上面找工作並不是常態;也有少數優質的找工作平台如:yourator、mit.job;不過一般大眾找工作幾乎還是依靠人力銀行居多。人力銀行上的資訊都是由公司刊登,雖然已經相當「豐富」,但缺少其他人的評價後,這些「資訊」能對求職者的幫助很有限,在自己成為資方以後,也開始理解為什麼很多老闆會選擇讓「資訊不透明」,這留到後面再說。

(對人力銀行來說縱容這些事情發生也很正常,畢竟他們主要是在服務企業,求職者對於人力銀行來說是商品,有個蠻經典的文章分享給大家:「你若不是顧客,你就是產品。」)

求職者找工作這件事,跟平常找餐廳吃飯其實有點像,儘管口味適合不適合很「主觀」,現在多數人決定要不要去這間餐廳時,第一件做的事情還是上網參考「別人」的食記來看。google 一下會發現,一開始也很多人說這種「評價餐廳」是「鄉民的正義」,怎麼可以讓網路上不相干的人來評價我的餐廳(公司)呢?不過在資訊流通越來越快的年代,時間也證明一切,這就是個不可逆的趨勢,我們如果還活在有網際網路的社會,那能做的就不是想辦法阻止這一切發生,而是提升自己判斷資訊的素養。求職天眼通現階段做到的就是讓求職者間能更快的交流這些資訊,所以我的動機很簡單,就是單純認為這東西本來就應該要存在,如果它不存在,那就自己做一個吧!

我是頭腦比較遲鈍的人,沒辦法同時做很多件事情,用 side project 的方式一定沒辦法比全心投入做得好,最後就決定暫時把自己全部的人生壓在這一件事情上了。

Photo Credit:screenshot
Photo Credit:screenshot

3. 評論工作、公司有什麼問題?

在網站上線時發了一篇 文章 , 沒多久後,貼文底下就有張總來回應請我刪除文章,張總其實算是這一整年下來中,最友善、理性的一位老闆,在幾次溝通之後他也能理解我們為什麼這樣做。但隔了一天,這個 po 文被轉上 ptt,

也第一次出現了支持者以外的批評聲;我想這應該是最突破自己同溫層的一次,因為我們開始受到質疑了,最主要的點莫過於這一個:「如何防止不實的評論?」這個質疑很直觀,但稍微想一下就會明白這是一個很顯而易見的藉口,因為每個人對於事物的看法永遠都是主觀的,沒有人有辦法保證任何主觀言論的「真實性」也是不言而喻的,用這個理由來否定掉所有資訊交流的價值,甚至去禁止這件事情發生,無疑是因噎廢食,不如自殺回戒嚴時代。所以思考到這裡,就明白這個問題的意思其實是:「如何防止所有人對我的企業評價?」,只是問的這些人不好意思說而已,對於這些人來說,這個問題的答案明顯是:「沒有辦法。」但退一步來說,這個問題的解方應該是:「如何產生好的評論?」,所謂好的評論並不是歌功頌德說公司有多麽的好,而是能反映更多公司內部或是面試情況的評論,這是我們接下來馬上就要改進的方向(從評論的格式和 UI 改起)。

這件事不只讓求職者省下時間,對於企業來說,也在這裡就過濾掉不適合的人,長期來看,這對於雙方來說都是有利的。既然是有利,那為什麼有些人會對這件事有疑慮?

先從企業認為對自己「不利」的評論來說:

因為「長期有利」這件事情不這麼顯而易見,短期來看,有些企業考慮到的點是投遞履歷、面試的人變少了,但不適合的人來面試,甚至錄取才是真正的虛耗;以往這些資訊都很不透明、流通速度慢,身為一個公司經營者並不需要這麼在意員工對自己的評價,(透過朋友打聽跟網路傳播比起來實在太慢)但是如果其他人在網路上會知道你有沒有做好,那對待這件事情的重視會上升到完全不一樣的層級。我也能理解為什麼有人會抗拒這件事,以已經變成一個資方的自己來講,要煩的事情已經很多了,為什麼要多煩一件事情?答案很簡單,因為尊重和好好跟員工溝通是本來就應該要做的事情,很多時候我們都以為自己做到了,但在員工的眼中並沒有,求職天眼通同時也是個能檢視這件事到底有哪裡做好跟做不好的地方。在這個越來越多人選擇出走的時代,我是衷心希望每個人在看待人才時,考慮的是更長期的利益,而不是像在買一個耗材;如果有企業願意好好做這件事情,我們也會花更多力氣在讓這些公司被人看到。

4. 職業風險

第一,是法律上的風險

任何工作可能都有風險,在求職天眼通工作最大的風險應該就是法律上的了。評論是匿名的,但匿名評論不代表不用負責任,也因此收到許多企業的檢舉,如果是指名道姓的辱罵、或者有具體事實,我們會通知該名用戶並且刪除這種評論(就是不需要我們去驗證,客觀就擺在那裡的事實,e.g: 根本就留錯公司)拜託,如果真的生氣,更應該沉住氣來告訴大家發生什麼事情但我們不會去充當法官來判斷這則評論是否違法,能做到的就是轉告檢舉的內容給這位留下評論的人。如果企業認為這些評論違法,那當然就照法律的程序走,也因此,我們接到了許多存證信函。現在講起來輕描淡寫,但每一次收到都還是害怕,加上一點沮喪,因為信件的內容很多都充滿威脅,大多也是跳針在上述說的:「不實評論」;還有很多會用高高在上的角度請你電話聯絡他,不然哼哼⋯⋯。

第二,則是人際上的風險

這裡的人際指的是親友以外的人。我不只一次聽到這句話:「這個圈子很小」、「得罪我就⋯⋯」之類的話。老實說,如果因為在網站上被評論就開始用威脅的,那好像本來就不該是同個圈圈的人,而且這種人大部分都是唯利是圖,有利益的話什麼都馬沒關係。

第三,家人的擔心

存證信函其實蠻多的,大部分也都會寄回老家去,家人收到時總是比我還緊張,跟他們解釋完,他們通常都會替我生氣:「你們又沒做壞事,為什麼要這樣?」「這樣值得嗎?唉呀台灣真的不行啦!」在確認自己想繼續做下去後,我還是會告訴話筒另一端的爸媽說「沒事」,也只能說沒事,爸媽都兩三秒就被說服了,想想他們真的很相信我這個兒子,甚至比我還要相信,每次講完電話後都只覺得自己更不能放棄。

5. 職涯發展

本來以為已經很幸運地結束對自己人生迷茫的階段了,現在卻走在更未知的路上;在大三那年開始寫程式,現在才第三年,中間跌跌撞撞寫過幾個專案,如果有人說我是業餘軟體工程師,一點都沒辦法否認,但要成為更專業的軟體工程師的這個目標,已是我確定想達成、且正在努力中的事情。

開始在「求職天眼通」工作後,能花在鑽研技術上的時間相對少了許多,但也逼迫自己更有效率地去掌握技能,以及處理雜事,之前 7/1 掉資料,也讓人一夜之間長大,重要的是我體會到 op 真的是需要環境和經驗。

如果有人想知道的話:

我重新用 serverless framework 做了一個確認備份的小服務,(啊~居然 1.0 了)有時候使用 Database as a service 的服務時,無法直接建立 snapshot 可能近期內會有一篇技術筆記講這件事情。團隊的另外兩位成員其實都不是技術人員,因此我也花了大量的時間在與他們溝通產品的作法,把困難生硬的技術,講到任何人都聽得懂絕對是我這一年進步最多的技能之一。

除此之外,如果有任何難以抉擇的事情,身為公司負責人的自己,也必須要做出決定來。同時也因為這樣,當我發言的時候代表的也不只是自己的立場,的確要考慮到更多事情。

6. 人

其實就是團隊還有這一年對外面到底遇到哪些人,除了內部比較熟的人之外,已經算是完全脫離舒適圈了。一起工作的人:當初決定團隊組成的時候,蠻幸運能找到憲祥和 YC。

兩位幾乎是在沒有猶豫的情況下就選擇加入,現在想想,他們簡直是瘋了(除了缺少設計師之外,我想不出有什麼缺點)也因為我們三個住在一起的關係,所以一天大概十幾個小時都耗在工作上,

工作結束以後吃個飯聊天也很容易又聊回工作上。除了寫程式他們沒辦法幫忙以外,幾乎所有事情我都可以百分之百的相信他們,這一年來,雖然真正開心的時候很少,但我認為能有人能這樣義無反顧地陪你把頭給洗下去是一件非常過癮的事情。當然還要感謝許多強大的顧問給我們意見,

雖然還離目標很遠,但很謝謝所有幫助過我們的人。

當然,也不乏奇怪的人來說奇怪的話,可以跟大家分享一下:

天眼通上會顯示公司違反勞基法紀錄,沒想到有公司來信說:「這個不能自己亂寫,請你們要負起責任⋯⋯」之類的,我們的資料其實是從各個勞動局公布的違法紀錄爬下來,並不是我們自己判定違法(會覺得我們自己判定哪些企業違法真的是蠻有創意),後來去看了一下這間檢舉的公司,在網站上有一筆違反勞基法紀錄,查證之後,還真的是我們搞錯了,原來是違反兩筆才對。還有希望我們將其他網站上的評論下架的(我們的網站只有這個)或是來粉專假裝私訊問問題,其實是釣魚想問我們公司地址的,(商業司就查得到了⋯⋯)說有東西要拿給我們,但一定要當面才比較方便給的(誰敢去啦⋯⋯)⋯⋯族繁不及備載。

一整年下來,EQ 還有看待人生的方式已經變得跟以前很不一樣。這裡還得再次感謝一個特別的人,就是我的女朋友,去年端午節我跟他去新竹玩時,帶著筆電去把天眼通的第一版完成;這一年裡面,不管我去哪裡,幾乎都還是帶著這台筆電 on-call,儘管偶爾會生氣,但最後總是很支持我,就算等到睡著也會等我把事情解決,謝謝你。

7. 下一步

待在一間公司工作,如果看不到未來我就會想要趕快走人,所以現在我想來說一下這間公司的未來。對於我們來說的第一步是要建立起大家開始談論工作的風氣,(大家對朋友都很會說,但到了網路上交流反而就有所顧忌)也因此把留言的限制降得比較低一些,不用填完太長的表單就可以完成;

在現在確認評論的風氣開始出現、也漸漸讓眾人知道以後,該追求的就是評論的質了,所以我們近期內就會把新的留言格式給更新上去。

這件事需要的是時間,讓子彈飛一會才能達到它的終極價值。接著還有一件更重要的事情,雖然現在很幸運的有了第一批用戶以及不少的關注,我們也明白在成長到一定程度後除了社會價值之外也會出現商業價值,但公司很可能在到那一天前就先死掉了,我們並不是慈善團體,一間公司要活下去要有一個可靠的商業模式,接下來這半年內會推出一些嘗試。近期的支持 qollie 並不是我們的商業模式,也不會是未來主要的收入來源,對於我們來說這其實也是產品的一部分,讓單純支持我們理念的人能夠參與接下來的每一步。

8. 小結

在天眼通的這個位置,能看到許多公司評價,求職者評論以及他們的行為,台灣人才的處境其實比原本想像的更糟,如果剛畢業的時候只是有點失望,那現在應該是接近絕望,不過「世界上只有一種真正的英雄主義,就是在認清生活真相之後仍然熱愛生活。」,儘管很多事情都讓我們很害怕,或者對於現實的醜陋感到無奈,我仍然覺得這份工作真的是蠻有意思的,推薦給大家。

如果你想要參與的話,可以:

在網站上寫下評論:https://www.qollie.com

支持 qollie: https://www.qollie.com/simpleDonate

follow 粉專:https://www.facebook.com/qollie.tw


開發者享受 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。

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