做大公司中層 還是細公司老細好？
=====
無論你是剛剛畢業，抑或是在職場打滾了幾年升職在望，只要你有上進心，你都會想到以下的問題：在未來的日子，我應該當一個細公司老細，還是繼續在大公司打工，一步一步踏上中層之路呢？

今天半宅職薯就和大家分析兩者分別，幫助大家思考前路。

履歷背景方面
如果你擁有專業資格或名校出身等亮麗履歷的話，你有機會如像坐直升機一般在大公司扶搖直上。因為亮麗履歷這華麗衣裳，會被視為競爭力的一部分。

但如果你打算當一個小公司老細的話，你便可以把你的亮麗履歷忘記。因為打從營商的第一天開始，你便踏入弱肉強食的商業森林，華麗衣裳對於覓食是沒有實際作用的。你需要的是具實戰能力的創意、執行力以及人脈。

工作時間方面
大公司中層雖然工作繁重，超時工作習以為常，但在假期日子，你的腦袋也可以有喘息空間，放下工事，讓自己身心放空。

但如果你是細公司老細呢？基本上你的上下班時間是不受任何約束的。但是這種自由僅限於肉身上的自由，你的腦袋24小時都是在想公事。至於長假，那便更加不用說了。要是讓自己放幾天長假，公司的生意便隨時停頓幾天，到最後也是自己損失。

資源需求方面
在大公司打工，你需要付出的資源便是時間、知識、精力。正常打工是不需要掏荷包返工的。付出了，到月尾自然會有收穫，雖然有時付出和收入不成正比。

而作為一個細公司老細，你不但需要擁有時間、知識和精力，更加要擁有豐富的創造力。在此，創造力是指創意加執行力。因為商場如戰場，當一道營商法則被發現為可行的時候，它便會很快變成不可行。因為每一間商戶都會爭相仿效，造成供應過剩，或欠缺差異。

另一項重要的資源，就是資金。細公司老細除了需要準備一筆創業資金外，更加需要準備可能長達兩年的生活費，等待收支平衡甚至有盈餘的時候，才有機會出糧給自己。

收入方面
當一個大公司中層，收入是有保證的。除非自己表現欠佳或者不幸遇上裁員，否則生活大致穩定。可以享受不時去旅行飲紅酒等中產生活，做得好的話甚至有車有樓。

而當一個細公司老細呢？你的收入是極其不穩定的。在最壞的情況，你可能需要負債；而在最好的情況，細公司可能變成大公司，收入無上限。心臟負荷力低一點的人，必須想清楚自己能否應付這種大起大落。

工作性質方面
當一個大公司中層，你大致上可以做自己最擅長的事。為什麼呢？因為大老細通常都會把適合的人安置到適合的崗位，發揮每一個人最擅長的才能。

而當一個細公司老細呢？雖然你可以選擇自己最擅長，最感興趣的行業，但那些自己厭惡和不擅長的工作，也責無旁貸。

細公司老細其實是銷售、人力資源管理、會計、產品開發、物流……等等多種角色集於一身的人。你不能說我不喜歡會計，便把它置諸一角，因為到最後責任也是由自己承擔。所以當一個細公司老細要不斷衝出舒適區，學習各式各樣的技能。

下屬管理方面
當一個大公司中層，大致上須要跟從能迎合公司文化的管理模式。這有好處也有壞處：好處是不需要自己揣摩一套管理方法，壞處是缺乏管理的自由度，發揮空間或多或少受到侷限。但若果你本身也十分接受公司文化的話，那麼要管理下屬便不是難事。

而當一個細公司老細呢？你可以創立出自己的公司文化。在這裏特別要提的是，細公司老細必須要有相當的辦公室政治智慧。當中目的不是在自己公司搞辦公室政治，而是杜絕一切辦公室政治。因為辦公室政治等於內耗，會燃燒你所給予下屬每一分一毫的薪金。

結語
說到這裡，大家應該對大公司中層和細公司老細有多一點的認識。簡單的說，大公司中層最吸引之處是穩定，細公司老細最吸引之處是收入無上限的機會。重點是你是否願意承擔風險。

大家可能會問：「在大公司中層和細公司老細這兩條路之外，有沒有第三條路可以走？」答案是有的，就是經營自己的副業！

https://seminerdlabs.com/learn-business/

#創業 #副業 #創業家 #企業家 #網店
=====
「半宅職薯研習所」提供：
一對一事業諮詢
網店副業或創業培訓(一對一培訓，手把手幫助你建立出可營運嘅網店！)
助你找到事業的出路。
立刻 Direct Message 半宅職薯
或 WhatsApp: 52444531

你知道嗎？在與人對話的時候，你如何表達自己的情緒，是影響溝通品質的關鍵之一。#文末抽課程​
​
你也許會好奇，一個人要如何在有不滿情緒的狀況下，保持風度的進行溝通？在我們一般的職場生活中，很常見到以下狀況：​
​
狀況一：「抽離」​
知道現在這些情緒對事情沒有幫助，所以選擇壓抑，努力專注於處理事情，但是冷冰冰的態度，不僅壓抑了自己，也讓他人的感受被忽略，雖然能夠解決問題，卻反而讓彼此的溝通產生更多隔閡。​
​
狀況二：「假裝」​
有些人可以藏起不愉快，同時臉上還露出自然的笑容，但只是延緩了情緒發作的時間，人前和善，人後卻怒罵，雖然表面上妥善處理了事情，但人前人後的表現卻會失去他人的信任。​
​
狀況三：「妥協」​
也有人雖然自己很不高興，但是為了維護彼此的關係，選擇全面的配合，吞下委屈。時間久了，大家都習慣把壞事丟給他，好事卻很少想到他。​
​
狀況四：「轉移」​
有些人會用其他高強度的情緒來掩蓋自己的不滿，例如用興奮愉快、活潑幽默，但有時嘻嘻哈哈的態度，在當下的溝通情境裡並不合適，給人缺乏尊重、不認真、沒有責任感的印象。​
​
上面提到的這些狀況，你常出現哪一種呢？​
​
其實，我們每個人都有很多很多的可能性尚未開發，只要你對自己如果有更多的認識，擁有更多表達自己情感的方式，溝通就會擁有更多的可能性。而「你更理想的模樣」，也許就藏在這些可能性當中喔！​
​
在得知綠光劇團的大熊老師（劉長灝）將在 Hahow 開設一堂應用於職場生活的【職場表演學：同理心表達自我，展現溝通魅力】時，我感到非常振奮，馬上翻開課程大綱來研究，一看完，忽然很感慨，對這堂課真是相見恨晚啊！​
​
很多人聽到「表演」，就會覺得跟自己無關，更不會想到要去學表演，因為他們認為，表演是舞台上、鏡頭前的事情，跟生活沒有關係，也不會為職場帶來幫助。​
​
不過我認為，學表演對於職場生活，至少有三個好處：​
​
➊ 學會表達自己，有勇氣去爭取權益、堅持正確的事​
➋ 學會同理的溝通，與他人平心靜氣的交流，並贏得尊重​
➌ 提昇工作價值，為不同的責任角色賦予意義，激發潛力​
​
好的情緒管理與溝通技巧，跟表演的能力有非常密切的關聯，甚至可以說，一個人若能夠把表演做得自然，他也就能輕易的轉化自己的情緒，並且用同理心與對方溝通。​
​
我認為學表演跟同理心的表現非常相似，在同理的溝通上，大致的過程是：找出自己的需求 —— 釐清對方的需求 —— 整合需求與資源，找出對彼此都好的方案。而要進入一個角色，過程則是：認識自己的特質 —— 認識角色的特質 —— 整合彼此的特質，賦予角色生命力。​
​
你發現了嗎？如何精準表達自己的需要，建立在認識自己的基礎上，而同理能力，則是來自你是否懂得讀人。這些能力，在表演的訓練當中，會非常紮實的在你的腦中與身體記憶中，建立一套屬於自己的系統。我自己也因為學配音的過程中，反而對人生有更多的啟發，所以我相信，這堂課一定也會帶領你看見更多。​
​
如果你跟我一樣，對這堂課充滿興趣，可以把握現在的募資價入手，也歡迎你在購買課程時，輸入我的專屬折扣碼，可以享有更多優惠喔！​
​
【#小虎老師專屬課程折扣碼】​
​
職場表演學：同理心表達自我，展現溝通魅力​
課程連結：https://linkingunitas.com/Lbear16​
9/3-9/9使用代碼「beartiger」可獲原價 666 元折價優惠！（課程原價2250元）​
​
一起來透過學習表演，開發屬於自己表達風格，並且創造溝通更多的可能性吧！​​
​
【#抽獎辦法：將抽出一位幸運兒，免費學習本課程】​
​
1.公開分享此篇文章​
2.在本文章留言 Tag 兩位好友：「＠XXX @XXX 在表達時，我常遇到的困擾是⋯⋯」​
3.留言截止日為 9/9（四）23:59，將於 9/10（五）公布得獎名單​
4.本課程將於 11/10 開課，得獎者將在開課前一週內完成兌換​
​
#感謝聯經出版與Hahow提供課程

ref: https://ably.com/blog/no-we-dont-use-kubernetes

八月第一篇，就來個有趣的文章，來看看 ably 這間 SaaS 公司為什麼沒有使用 Kubernetes，不但當前沒有使用，甚至短期未來內都不會想要使用
更是直接的說如果你有興趣來加入團隊，千萬不要把將 Kubernetes 導入到團隊中是一個可能發生的事情。

我個人覺得這篇文章滿好的，因為是認真的去比較導入 Kubernetes 帶來的改變，而這些改變對團隊來說到底是可接受還是不可接受
而不是所謂的人云亦云，人家要我也要，人家不要我也不要...

文章分成兩部分，前述介紹當前 Ably 的環境架構是什麼，而半部分則是很技術的去探討如果導入 Kubernetes 帶來的好處與壞處是什麼
最終權衡比較之下，會發現導入 Kubernetes 沒有帶來實質上的好處。

文章開頭先簡述了一下 Kubernetes 這幾年的風潮，從最初 Google Borg 的開發開始談起，作者特別提到當初 Borg 的用法可是將一堆實體機器給搭建出一個 Private Cloud 的叢集給團隊使用，
而目前 Kubernetes 更多的用法則是搭建於 Public Cloud 上面的虛擬機器中，透過將 Kubernetes 部署到這些不同的 Cloud Provider 似乎帶來了介面統一的結果，對於 DevOps 人員來說
不同 Cloud Provider 如今看起來都是 Kubernetes 的樣貌。

Ably 目前到底怎麼部署應用程式
Ably 主要使用 AWS 作為其 Cloud Provider，並且於 EC2 機器上使用 docker/container 來部署團隊中的應用程式。
作者團隊中沒有使用任何已知的 Orchestration 服務來管理多節點上的 docker/container，取而代之的則是每個 VM 開機後則會根據 autoscaling group 的機制來判斷
每個機器應該要部署哪種 container/docker。

對於 Ably 來說，團隊中沒有任何 scheduler 相關的服務來調度各種服務，這意味每個 VM 就代表一種服務，所以將 VM 上的服務從 Core 轉換成 frontend 這種行為不會發生。
今天需要針對需求轉換服務時就以 VM 為基準來整批換掉即可。
每個節點上面都會有一個輕量的監控服務，用來確保運作的 Container 如果掛掉後可以被重啟，甚至如果當前運行的版本不符合需求時也能夠將該服務給停止。

流量方面，因為每個 Autoscaling Group 就代表一個服務，所以直接使用 NLB 與 Target Group 來將流量導入該 Autoscaling Group 即可。
至於容器與容器之間的內部流量(譬如 k8s service 等)作者認為也不是太大問題，畢竟每個機器本身都會被 VPC 賦予一個 IP 地址，所以使用上沒有什麼太大的問題。

接下來作者從幾個層次去探討當前設計與使用 Kubernetes 帶來的改變，分別有 (原文很多，這邊摘要不然文章會太長)
題外話，由於 Ably 的 Infra Team 數量有限，所以要考慮 K8s 只會考慮 K8s Service，如 EKS。
1. Resource Management
Ably:
a. 根據服務的需求來決定每個服務要用到的 VM 等級
b. 不需要去煩惱如何處理將多個小服務給部署到一個適合的大 VM 中
c. 作者稱這種行為其實就是 AWS 官方強調的 Right Sizing, 譬如只能跑兩個 Thread 的服務不需要 16vCPUs, 久久寫一次硬碟的服務也不需要一個 90,000 IOPS 的 SSD
d. 選擇一個正確的元件來搭建一個符合服務的 VM 讓團隊可以控制成本同時也減少額外的管理負擔
K8s:
a. 必須要使用一個比較強大等級的 EC2 VM，畢竟上面要透過 Container 部署很多服務
b. 針對那些需要小資源的服務來說，透過這種方式能夠盡可能的榨乾機器的資源，整體效能使用率會更好
c. 但是針對資源量沒有很辦法明確定義的服務則是會盡可能地去吃掉系統上的資源，這種被稱為 nosy neighbors 的常見問題已經不是首次出現了， Cloud Provider 本身就需要針對 VM 這類型的服務去思考如何處理資源使用，而 Cloud Provider 都有十年以上的經驗再處理這一塊
而所有 Kubernetes 的使用者則必須要自己去處理這些。
d. 一個可能的作法則是一個 VM 部署一個服務，不過這個做法跟團隊目前的作法已經完全一致，所以就資源管理這一塊，團隊看不到使用 Kubernetes 的優勢。

2. Autoscaling
Ably:
a. EC2 VM 本身可以藉由 Autoscaling Group 來動態調整需求
b. 有時候也是會手動的去調整 EC2 的數量，基本上手動跟自動是互相輔佐的
c. 團隊提供的是 SaaS 服務，所以其收費是針對客戶實際上用多少服務來收，如果開了過多 EC2 VM，則很多不要的花費與開銷都是團隊要自行吸收
d. 團隊需要一個盡可能有效率的方式能夠即使遇到流量暴衝時也能夠保證良好的服務的機制
K8s:
a. 可以透過不少方式來動態調整 Container 的數量，
b. 甚至可以透過 Cluster autoscaler 來針對節點進行調整，根據需求關閉節點或是產生更多節點
c. 動態關閉節點的有個問題是關閉節點時通常會選擇盡可能閒置的節點，但是閒置並不代表沒有任何服務部署再
上面，因此該節點上的 Container 都要先被轉移到其餘節點接者該目標節點才可以被正式關閉。這部分的邏輯作者認為相對複雜
d. 整體來說，k8s 有兩個動態調整的部分，動態節點與動態服務，而現有的架構只有一個動態節點。所以使用 k8s 則會讓問題變得更多更複雜。

3. Traffic Ingress
Ably:
a. Traffic Ingress 基本上每個 cloud provider 都提供了很好的解決方案，基本上團隊只要能夠維持每個服務與背後的機器的關係圖，網路流量基本上都沒有什麼需要團隊管理的。
b. 使用者會透過直接存取 NLB 或是透過 CloudFront 的方式來存取團隊內的服務

K8s:
a. EKS 本身可以透過 AWS VPC CNI 使得每個 Container 都獲得 VPC 內的 IP，這些 IP 都可以讓 VPC 內的其他服務直接存取
b. 透過 AWS LB Controller，這些 Container 可以跟 AWS LB 直接整合，讓封包到達 LoadBalancer 後直接轉發到對應的 Container
c. 整體架構並不會比團隊目前架構複雜
d. 唯一缺點大概就是這個解決方案是完全 AWS 綁定，所以想要透過 k8s 來打造一個跨 Cloud Provider 的統一介面可能就會遇到不好轉移的問題。

4. DevOps
Ably:
a. 開發團隊可以透過簡單的設定檔案來調整部署軟體的版本，後續相關機制就會將 VM 給替換掉，然後網路流量也會自然的導向新版服務
K8s:
a. 開發團隊改使用 Kubernetes 的格式來達到一樣的效果，雖然背後運作的方式不同但是最終都可以對開發團隊帶來一樣的效果。

上次四個分析基本上就是，使用 k8s 沒有帶來任何突破性的好處，但是 k8s 本身還有其他的功能，所以接下來作者想看看 k8s 是否能夠從其他方面帶來好處

Multi-Cloud Readiness
作者引用兩篇文章的內容作為開頭，「除非經過評估，否則任何團隊都應該要有一個跨 Cloud-Provider 的策略」
作者表明自己團隊的產品就是那個經過評估後斷言不需要跨 Cloud Provider 策略的團隊，同時目前沒有往這個方向去追求的打算。
同時作者也不認為 K8s 是一個能夠有效達成這個任務的工具。舉例來說，光 Storage 每家的做法都不同，而 K8s 沒有辦法完全將這些差異性給抽象畫，這意味者開發者終究還是要針對這些細節去處理。

Hybrid Cloud Readiness
管理混合雲(Public Cloud + Private Cloud based on Bare-Metal servers)是作者認為一個很合理使用 K8s 的理由，畢竟這種用法就跟當初 Google Borg 用法一致，是經過驗證可行的。
所以 Ably 如果有計畫要維護自己的資料中心時，底層就會考慮使用 Kubernetes 來管理服務。畢竟這時候沒有任何 Cloud Provider 提供任何好像的功能。
不過 Ably 目前沒有任何計畫，所以這個優點也沒有辦法幫助到團隊

Infrastructure as Code
團隊已經大量使用 Terraform, CloudFormation 來達成 IaC，所以透過 k8s YAML 來維護各種架構不是一個必要且真的好用的方式。

Access to a large and active community
另外一個很多人鼓吹 K8S 的好處就是有龐大的使用者社群，社群內有各種問題分享與探討。
作者認為
a. AWS 的使用者社群數量是高於 Kubernetes
b. 很多情況下，一個迭代太快速的產品其實也不一定對團隊有太大的幫助。
c. 很多人都使用 k8s，但是真正理解 k8s 的人微乎其微，所以想要透過社群來幫忙解決問題其實比你想像的還要難，畢竟裡面的問題太雜，很多時候根本很難找到一個真正有效的答案。

Added Costs of Kubernetes
為了轉移到 K8s, 團隊需要一個全新的 team 來維護 k8s 叢集以及使用到的所有基本服務。舉例來說，EKS, VPN CNI, AWS LB 帶來的網路好處並不是啟動 EKS 就會有的，
還必須要安裝相關的 Controller 並且進行設定，這些都是額外的維運成本。
如果找其他的服務供應商來管理 Kubernetes，這意味公司就要花費更多的$$來處理，所以對團隊來說，金錢與工作量都會提高，不同的解決方式只是這兩個指標的比例不同而已。

結論:
1. Ably 覺得 Kubernetes 做得很好，但是團隊目前沒有任何計畫去使用它，至少目前這階段沒有看到任何實質好處
2. 仔細評估後會發現，導入 k8s 其實也會帶出不少管理上的問題，反而並沒有減輕本來的負擔