Search
當使用Gitlab在進行檔案產出時 可能會遇到容量過大的情況 這個部分可以先從nginx的限制查起 在nginx的設定檔中加上 client_max_body_size =0; 這個參數後再reload服務 (如果你有很多層nginx, 就每一層都要加...) 接著進Gitlab的介面管理後台 在Setting頁面內 找到CI/CD的設定 將Maximum artifacts size (MB)設定需要的上限 (這個選項可能會因為gitlab版本不同而出現在不同名稱的選單內) 這樣應該就可以了
https://mshw.info/mshw/?p=26214
【Amazon公布S3故障原因的解釋】
Amazon的雲端服務AWS S3於2月28日在美國地區大當機接近4小時，導致Adobe、Slack、GitHub、Airbnb、《Business Insider》、《The Verge》、時代雜誌等公司和政府機關全都受到波及，也讓亞馬遜股價在當天硬生下跌了0.4%。
昨天AWS發布了一份報告，解釋這次癱瘓的原因：
有一個工程師在調查S3的一個帳務系統時，本來是想要刪掉S3子系統的一小部分伺服器再重建資料。
結果打錯了一條命令，刪掉了一大堆本來沒有要刪的伺服器，其中包括兩個S3重要的子系統。
─“Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended.”
與GitLab在1/31發生的伺服器誤刪事件一樣，該工程師本來要刪掉故障的二號伺服器、結果誤刪到正常的一號伺服器，永遠丟失了六小時的資料量😑😑
只能說兩次事件都正好是工程師的Fat Finger (這個詞栩栩如生的描繪了手滑👆) 造成的。
工程師爆肝到神智不清的情況下、隨便敲錯一個Bug，和遊覽車因疲勞駕駛駕駛撞車的情況差不多… 只能說無論是Command Line還是開車，只要是給人用的工具，都得加上一定的防呆設計。
Amazon在報告中將問題剖析成兩個方面：
1. 以後要怎麼預防人為誤刪資料？(防呆設計)
—將刪除速度變得更慢以好反悔、加一個伺服器最小容量限制的Safeguards等等。
2. 誤刪後要怎麼改善恢復的速度？(4小時實在太久)
—將大型服務進一步分解為一塊塊的小Cell，讓工程團隊在測試服務或恢復流程都能更快。
🤡 Lynn 短評🤡
GitLab和Amazon在過失發生後，都很有誠意的將問題和改進方式明確寫成了文章放在網路上，即使是超低級的人為疏失也絲毫不掩蓋...哪怕會影響投資人信心。(GitLab還開在YouTube直播搶救的過程!!!)
國內廠商常見作法可能是將原因推託給硬體故障之類的，然後叫客戶去找硬體商吵架🤐 只能說這次GitLab和Amazon的公關雙雙滿分！這才是消費者想要的態度😑
註：GitLab網站創立於2014年，目前已獲得2,000萬美元的B輪融資。
提供的服務和GitHub差不多，都是Git託管服務，然而在GitHub創建專案時，若是程式碼開源出來就免費、想私人鎖起來就要錢；GitLab則是私人專案也免費。
什麼，你說你不知道什麼是Git和Github？好吧，歡迎您參考我的文章🤗🤗🤗
傳送門：
👉 Amazon故障分析報告：https://goo.gl/Ke6bIY
👉 GitLab故障分析報告：https://goo.gl/YoEBcX
👉 GitLab直播搶救過程：https://goo.gl/UrIKEO
👉 Git與GitHub教學：https://goo.gl/GBhf8z
