乙個pro環境中的openstack集群，在倒下後1個月還沒完全恢復，我也是醉了。如果不在這裡，實在無法想象到外企的工作效率。
不過還好坑的只是部門內部的人，倒也沒鬧出什麼大的么蛾子。
乙個月下來，有些感想，僅作記錄吧。
1.永遠不要低估乙個線上操作的影響。
線上的每個操作，都應該在beta環境經過測試驗證沒有危害才能實行。有些操作可能看起來只會影響那麼一點，但是總會有那些隱藏的side affect.
2.乙個和pro環境一致的beta環境。
beta環境的重要性是毋庸置疑的，用beta環境首先得明確beta的作用，它存在的意義應該是為pro環境變化做實驗。像我們不停的拆東牆補西牆，把beta環境拆的亂七八糟的來緩解 pro環境的危機是不可取的，這樣做只會讓pro環境越來越亂，beta環境越來越凋零。
所以乙個好的beta環境應該是：
a.架構和pro基本一致，且不說一致到機器型號，整個集群的架構應該是一致的，比如多台cn，一台cc
b.os，軟體版本必須一致
3.操作許可權管理
對集群的操作許可權管理是個很蛋疼的問題，既要不影響平時的開發運維，又要防止不可靠之人（比如我）的瞎眼操作。
對於配置的更改： puppet 自動化部署已經不是新鮮事了，但是總會有人偷懶自己去改配置而不是通過puppet，所以總會有一些詭異的事發生。
對於需要admin許可權的操作：我覺得對horizon的許可權應該開放給基本可靠之人，運維工作人員也算是半個admin，如果和普通使用者一樣的許可權，那活就沒法幹了，當然也可以不怕麻煩的設定個半admin狀態的使用者，可以自己去慢慢grant一些許可權。
4.凝聚力
乙個混日子的團隊是不會有高的工作效率，作為乙個scrum的團隊，既然人不多，就應該要關注到每個人的情緒和狀態。木桶效應隨時會在teamwork中發生，乙個積極性不高的人，可能會影響整個團隊工作的進度，卡殼會經常發生，這樣的話，頻繁的迭代還怎麼實現。
可能不是每個人都對別人的感覺很敏銳，so，這一點，只能看scrum master是否優秀了吧。
ps： 雖然集群恢復的很慢，但是這乙個月來我的收穫還是蠻大的。作為乙個才來的時候linux一竅不通、搭個3節點都要乙個月的人，前幾個月都是幹一些邊角活，起碼現在我能接觸到組裡最核心的東西了。
可是這乙個月的代價未免也太大了。
OpenStack運維記錄 清理docker日誌
問題現象 根目錄占用磁碟空間過高，導致ceph健康狀態為warn。檢視當前各目錄占用的磁碟大小。df h 查詢根目錄占用空間較大的目錄。du h max depth 3 發現docker日誌檔案目錄 var lib docker containers占用空間較大。進一步查詢該目錄占用空間大的檔案。f...
運維維護感想
今天鄭璐璐想給 bill 的ubuntu 這是耐心的問題。方案 要有內心，不要怕耽誤時間，解決問題的能力和 能力同等重要。今天坤哥來了，一看錯誤，就問是不是沒有聯網，這是經驗 方案 1 多去解決，2 多去接觸原理性問題。而我開始僅僅是想當然的以為璐璐已經配置好了網路，其實自己下次可以先去實踐檢測，或...
運維（1）什麼是運維
運維，這裡指網際網路運維，通常屬於技術部門，與研發 測試 系統管理同為網際網路產品技術支撐的4大部門，這個劃分在國內和國外以及大小公司間都會多少有一些不同。乙個網際網路產品的生成一般經歷的過程是 產品經理 需求分析 研發部門開發 測試部門測試 運維部門部署發布以及長期的執行維護。對於初創公司，運維部...