對於網際網路創業團隊來說，初期的公司規模小，業務量不大，人員不齊，**部署發布不規範偶爾導致**宕機的錯誤成本沒有太大體現。
當業務量上來後，不管是使用者體驗還是企業信任角度來說，人為可消除的宕機事故就非常嚴重了。
對於此次事故，首先要擺正自己的認知態度，部署是自己成果的對外交付，可以說是最神聖的事情。需要做到對自己負責，對工作負責，對公司負責。其次做事就要有做事的樣子，要足夠專業，要求自己更專業的去做事。
對於乙個成熟產品來說，功能的公升級固然是重要的，但是確保系統執行穩定，效能可靠是更重要的事情。
由於目前還做不到完全自動化部署，在此分享一下當前的部署方案，還有提出一些防範措施。
1.跳板機的使用
發布操作，使用跳板機安全管理，許可權管理。
2.流量切分平滑部署
舉例2臺伺服器：部署1號機器，先將全部流量切到2號機器，部署完1號機器，再平分流量到1/2號。部署2號機器，將全部流量切到切到1號機器，部署完2號機器，再平分流量到1/2號。
每台機器部署完要確保機器服務程序正常，服務日誌正常，頁面訪問正常。
3.視窗期
對於核心系統，設立發布視窗期，比如每月15號。
4.掛維護
對於耗時較長的發布，需要在系統影響最低的時間發布，並掛維護頁面通告。
5.規範化
沒有上過測試的**，不能發布。
系統忙時盡量不發布。
發布時，所有**相關人員在場等發布完。
發布時嚴格按照發布流程發布，並做到：發布－檢查－確認。
發布責任人輪值制度
專案管理的所思所想
這裡所說乙個最基本的解決方案。如果最先和客戶談錢那就就等著挨砍吧，先砍你價錢，再砍你時間，最後加點功能，要點回扣，左一刀右一刀，砍到專案 身亡還拖你尾款。通過以下四步來達到我們的目標 搞清客戶的要求，找出要求的邏輯，客戶想要的結果，同時排除開發的風險，挖掘與控制潛在的要求。下面咱們來一一討論。第一步...
關於scratchpad修改所想到
今天花了將近一天的時間修改乙個低優先順序的cr，不是coding太慢，而是自己在兩種解決方案中徘徊，開始選擇一種方案，但是後來發現這種解決方案，給目前系統帶來了很大的不確定性，雖然可以很好的解決問題，但是修改太多，其中很多邏輯都要發生變化，需要將很多測試用例重新測試一遍，可能導致引入更大的風險。直到...
關於自動發布專案的經歷總結
見到過的打包發布過程 發布本質 上次發布中的指令碼 bin sh export project home home admin projects zongzhi center 用於建立附件的軟鏈的源目錄 export link source home home admin share 專案字首 ex...