DevOps

什麼是DevOps

隨着軟件發佈迭代的頻率愈來愈高，傳統的「瀑布型」（開發—測試—發佈）模式已經不能知足快速交付的需求。2009 年左右 DevOps 應運而生，簡單地來講，就是更好的優化開發(DEV)、測試(QA)、運維(OPS)的流程，開發運維一體化，經過高度自動化工具與流程來使得軟件構建、測試、發佈更加快捷、頻繁和可靠。

DevOps 的技術棧與工具鏈

• 版本控制&協做開發：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar

• 自動化構建和測試:Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit

• 持續集成&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go

• 容器平臺: Docker、Rocket、Ubuntu（LXC）、第三方廠商如（AWS/阿里雲）

• 配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible

• 微服務平臺：OpenShift、Cloud Foundry、Kubernetes、Mesosphere

• 服務開通：Puppet、Docker Swarm、Vagrant、Powershell、OpenStack Heat

• 日誌管理：Logstash、CollectD、StatsD

• 監控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana

---

 

我的很贊同的兩個觀點

簡單

KISS（Keep it Simple and Stupid，簡單就是美）原則是最重要的。因此本段文字也很簡單。咱們要儘可能提供簡單、可重用的解決方案。「簡單」節約了書寫文檔、培訓和提供支持的時間。「簡單」增長了溝通的速度、避免混淆、減小了開發和運維出錯時的風險。「簡單」讓人更快的發佈產品。

開發與運維的關係

早參與，多參與。對於開發人員，要讓運維人員常駐到開發部門，全程參與開發流程。邀請運維人員參與你的Scrum或者開發會議，與他們分享項目計劃、分享新技術的點子和心得。蒐集功能性需求（指開發人員用到的需求）的同時也要蒐集運維方面的需求。把對於「發佈、備份、監控、安全、配置管理和系統功能」的測試做爲一項獨立的項目流程。軟件產品在開發時解決的問題越多，那麼在使用時暴露給用戶的問題就越少。給運維人員作培訓，讓他們弄清楚項目的體系結構和核心代碼。若是運維人員在反饋bug時提供的信息越多，那麼你花在排查問題 的時間就越少，這個bug也就會更快的被解決掉。

對於運維人員，在遇到問題時須要把開發人員加進來，你們一塊兒解決問題。邀請開發人員參與大家的會議，分享項目進度（roadmaps），而且共同修訂工做計劃。運維人員必定要了解開發部門下一步的工做方向，從而確保產品運行的底層平臺可以良好的支持最新技術。開發人員也會帶來相關的技術、知識和工做，幫助大家改善產品的運行環境，使其更加易於維護、簡潔有效。

有一些開發領域的概念，例如：「要根據API而非封閉的interface來構建工具」，分佈式版本控制，驅動測試開發，以及諸如敏捷開發、看板管理（Kanban）和Scrum等方法論。若是把這些概念應用在運維領域，一樣會產生革命性的變革。

不要害怕新點子和新技術。咱們能夠隨時隨地的向他人學習，哪怕是一句「咱們不再要那樣作了！」也會讓咱們從中獲益。儘管處於不一樣的部門，可是咱們要共同窗習、共同成長，這樣才能協同工做的更好！