說到devops凡是在技術圈子的基本都聽到過，但是總是感覺虛無縹緲，要想實現總是還很遙遠。
現象
在傳統模式下，度量開發團隊效率的途徑就是看開發完成了多少需求，有沒有如時交付產品。於是，開發為了達成績效目標，當然也是為了滿足業務需求，不斷地堆砌新功能，卻很少有時間認真思考這些功能的可運維性和可測試性，只要需求狀態流轉到開發完成就萬事大吉了。
而對於運維團隊而言，他們的考核指標卻是系統的穩定性、可用性和安全性。但現代 IT 系統是如此複雜，以至於每一次的上線發佈都是一場戰役，整個團隊如臨大敵，上線失敗的焦慮始終如影隨形。
另一方面，在無數次被開發不靠譜的功能缺陷蹂躪得體無完膚之後，運維團隊意識到，變更才是影響他們績效目標的最大敵人。於是，預先設立的上線窗口就成了運維團隊的自留地，不斷抬高的上線門檻也使得開發團隊的交付變成了不可能完成的任務，最後，“互相傷害”就成了這個故事註定的結局。
如圖：
什麼是devops
- 提高組織高速交付應用程序和服務的能錄
- 更快的發展和改進產品，更好發服務於客戶
- 提高在市場上的產品競爭力
如圖：
說白一點：通過自動化軟件交付和架構變更的流程，使得構建、測試、發佈軟件能夠更加快捷、頻繁和可靠
實現DevOps需要什麼
1.硬性要求：工具上的準備，本系列選擇工具已加粗
- 代碼管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
- 構建工具：Ant、Gradle、maven
- 自動部署：Capistrano、CodeDeploy
- 持續集成（CI）：Bamboo、Hudson、Jenkins
- 配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
- 容器：Docker、LXC、第三方廠商如AWS
- 編排：Kubernetes、Core、Apache Mesos、DC/OS
- 服務註冊與發現：Zookeeper、etcd、Consul
- 腳本語言：python、ruby、shell
- 日誌管理：ELK、Logentries
- 系統監控：Datadog、Graphite、Icinga、Nagios zabbix，Prometheus
- 性能監控：AppDynamics、New Relic、Splunk
- 壓力測試：JMeter、Blaze Meter、loader.io
- 預警：PagerDuty、pingdom、廠商自帶如AWS SNS
- HTTP加速器：Varnish
- 消息總線：ActiveMQ、SQS，kafka，RocketMQ
- 應用服務器：Tomcat、JBoss
- Web服務器：Apache、Nginx、IIS
- 數據庫：MySQL、Oracle、PostgreSQL等關係型數據庫；cassandra、mongoDB、redis等NoSQL數據庫
- 項目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker
2.軟性需求：文化和人
DevOps成功與否，公司組織是否利於協作是關鍵。開發人員和運維人員可以良好溝通互相學習，從而擁有高生產力。並且協作也存在於業務人員與開發人員之間。
這樣，工程師們使用通用的平臺（即打通的工具鏈）得到更好的一致性和更高的質量。此外，DevOps對工程師個人的要求也提高了，很多專家也認為招募到優秀的人才也是一個挑戰。
在工具的選擇上，需要結合公司業務需求和技術團隊情況而定。
下一節從jenkins 開始介紹
如果對您有幫助，記得不要忘了給個關注哦！！！#上海IT故事#
還可以關注我之前的文章：
監控系列 Prometheus
閱讀更多 上海IT故事 的文章
