引用:
作者A級黑豬肉
所以我當時一直講千萬不要這樣幹... Data 的頭頭就說一定要這樣用因為他自認為很厲害... 而且不是純 Datalake 喔∼是 hybrid... Datalake + transactional 用相同 schema... 我聽完就說哇塞這麼厲害應該早就坐鎮 MS 的 Azure Database Director了吧...
|
Datalake + transactional 用相同 schema........
我也遇過一次, 這真的很可怕
還是我剛接手的系統, 被我擋下來了, 沒有做
不然就吐血身亡了
工程師在掰什麼 datalake Wide-column store..... 可以怎樣怎樣多好多好
背後技術不就是mongo 或 cassandra 之類的 nosql 嗎?
贛! 你還是給我乖乖用 RDB!
太多工程師和SA對這些技術工具一知半解
更可怕的事情是, 這些人連應這些工具的用場景和限制也不了解
根本把系統當作自己練功的白老鼠
想用什麼新技術看起來好像很好用就了, 反正老闆也不懂
最後爆了, 留下爛攤子給老闆, 自己離職
引用:
作者A級黑豬肉
所以每次發生網頁 performance 上的問題... 瓶頸都會是那個可惡的 SQL... 然後結論就是再往上升級... ... ... 都跑到 metal 了接著竟然跑去跟 AWS sales 問有沒有 2xmetal...
|
不意外啊, 看過很多次了
程式寫得很爛卻怪SQL主機不夠力
IOPS都開到最大5萬和32GB RAM+四台做讀寫分離, 才勉強跑順
卻跑不了多少報表和業務, 線上也沒幾個user
系統會OOM, 怪維運單位沒有及早發現問題
這些工程師, 什麼都是別人的問題
就是不會檢討自己才是問題的根源
引用:
作者A級黑豬肉
每個禮拜 Sprint 的 Goal、Scope、和 Priority 非常非常重要... PDM 和工程師都要非常確定他們是在「領導」客戶... 而不是被客戶拉著走... 因為幾乎所有客戶都不知道他們到底想要啥... 他們只能看到東西後才反應這不是他們想要的... 所以才會訂定架構好 CI/CD 後每個禮拜客戶看的到新東西... 他們的老闆也能知道進度。
|
要領導客戶太難了
這需要很強力的PM和SA, 對領域知識部分不輸給客戶, 甚至要比客戶更了解
這需要卓越團隊才能做到, 可遇不可求
大多數都是就像你說的被客戶拉著走, 加上客戶對自己需求也不甚了解
然後乙方也不打算去了解
所以一整個改改改改改改改改改改改改改改改改改改改改的重工就反覆發生
老闆花了大錢卻做不出個什麼東西