XP+devOps開發模式與scrum敏捷開發對比,docker虛擬化
我們現在用的就是典型的XP+devOps模式，已經放棄scrum了
現在還很多公司弄docker虛擬化
docker非常復雜，當然如果只是用別人的只用記一個docker命令就行了
docker虛擬化消耗額外的系統資源較少 傳統虛擬化會占用一點系統資源。通常日志是寫在掛載進去的盤 或者直接通過其它協議扔給日志中心服務器
傳統虛擬化 啟動 銷毀 部署 時間都較長
docker部署這些就很短 把一個應用(nginx php node) 等等當成一個服務來用
devOps模式 聽朋友說他公司里面執行起來不容易
要各部門配合得很好才行
主要是人的問題， devOps對核心程序員要求極高，一般都得是全棧程序員，而且基本上研發團隊都必須是
一個能夠做devOps的團隊，核心程序員必須是后台運維高手，能夠自己編寫虛擬機腳本，熟悉vagrant，docker ，snappy這些，會寫自動化腳本
一般的公司做不了的，你哪里能招到這么多全棧的
只能是全部招有多年經驗的了
其實一般三個牛人，並且性格足夠互補，超過幾十倍的由一般人員組成的團隊
而且這幾個最好是合伙人或者聯合創始人
不過也是很難找到剛好互補又能夠一起出來創業的
===========================================
http://blog.oneapm.com/apm-tech/687.html
DevOps 發展融合運維可視化
DevOps，是開發（Development）和運維（Operations）的組合，代表一種文化、運動或實踐，旨在促進軟件交付和基礎設施變更軟件開發人員（Dev）和 IT 運維技術人員（Ops）之間的合作和溝通。它的目的是構建一種文化和環境使構建，測試，發布軟件更加快捷，頻繁和可靠。
現在2016年 DevOps 逐漸成為主流，來自雲端、移動和社會等基本需求的驅動將促使越來越多的公司認識到采用 DevOps 最佳實踐可能獲得的文化、性能和經濟效益。
精簡靈活的公司已經在過去幾年感受到了 DevOps 和持續交付帶來的好處，而成熟的大企業也意識到了它們的價值，開始進行文化轉型。但是這些企業對待 DevOps 的態度相當謹慎。所以預計在2016年，在廣泛使用 DevOps 之前，企業會在非關鍵的新 IT 項目中進行 DevOps 測試實踐，這將涉及進程、自動化、協作和工具等方面，其間的協同合作也極大的提升了工作效率。
通過查看 IT Central Station 中關於 DevOps 解決方案的真實用戶評論，可以發現研究和購買 DevOps 解決方案的用戶已經發生了變化。之前，許多評論都是 DevOps 經理和發布經理寫的。現在則會看到很多 IT 行業的其他職能單位---架構師、客戶服務經理、中間軟件專家、網絡工程師及其他人寫的關於 DevOps 工具的評論數量正在增長。DevOps 工具正被越來越多的主流 IT 買家列入2016年的預算當中。
現在，較為成熟的 DevOps 購買方都來自軟件和技術世界，這類買家往往很早就采用了現代實踐和技術。不過另一面，較大型的企業和財富500強公司的 DevOps 采用率也在在逐步攀升。預計2016年，DevOps 將成為一項優勢策略得到全面的普及與實踐。
大型企業將更多地采用 DEVOPS
2016年，更多大型公司或組織最終將擁抱 DevOps 解決方案。在未來12個月內，將出現更多更為精密的工具，用於實現數據分析和問題解決依賴的關聯自動化，包括跨系統基礎設施智能洞察，從而降低部署共享或聚合計算、存儲以及網絡資源的性能風險。
作為整體戰略的一小部分，全球5000強企業將不斷產生 DevOps 團隊。而且隨着新軟件和工具以及 QA 技術的使用，這一勢頭有望增長。我們不能那樣做，因為這將破壞產品質量和安全－－－這樣的日子將隨着 DevOps 優勢的逐步顯露而漸行漸遠，新的 QA 技術也可用於處理那些問題。
全球5000強企業將開始在公開論壇上談論他們的舉措以及隨之而來的直接成本效益，並對其獲得的成就引以為豪。雖然真正的 DevOps 對於運營着10000個應用的大型企業來說，比那些只有一個主要應用的軟件公司來說更具挑戰性，但這些大企業哪怕接納部分 DevOps 文化，也能收獲極大的效益提升。
2016年，DevOps 運動將開始影響傳統的開發團隊，他們可能還無法完全發展過渡到到真正的 DevOps 進程，但他們可以而且應該接受一些必要的 DevOps 概念。自然而然地，他們會從協作入手，繼而開始更加注重終端用戶、敏捷度、自動化以及測量機制。最后，也是最重要的，開始以性能為准則。
小型 IT 團隊更多地采用 DevOps
2015年由於大多數 IT 環境變得日益復雜，DevOps 的受眾群從小眾群體和早期采用者，逐漸演變為主流公司與組織。隨着2016年的到來，我們相信，正在經歷開發策略文化轉型的小型 IT 團隊將更多地采納與使用 DevOps 方案。DevOps 使得開發變得更加快速靈活，因此提高整個 IT 團隊的效率。
DevOps 最佳實踐產生
2015年 Gartner I&O 自動化技術成熟度曲線表明，DevOps 正處於期望膨脹期的頂峰。實際上在許多 IT 組織內部，只有少數處於實驗階段的應用在使用 DevOps 准則。雖然這些公司目前還未准備好將 DevOps 作為主流方案，但他們對敏捷性和快速上市時間的追求卻是毋庸置疑的。預計2016年越來越多的 IT 組織將試圖尋找最佳實踐（理想情況下是從其所在行業的其他公司中入手）以此加速他們的 DevOps 之旅，並最大限度地減少痛苦的教訓。
在軟件開發領域，DevOps 仍處於新興階段，且該實踐目前還沒有明確的標准，這就導致企業猶豫是否完全接納這種文化轉型。2016年將看到各個公司建立其他們自己的標准。漸漸地，最佳實踐也會出現，並應用於所有行業。
APM：至關重要的 DEVOPS 技術
2016年，我們將看到以下幾大進展：開發環境進一步虛擬化和雲化，甚至開發人員的工作站都將變得更加虛擬化；通過各種舉措來增加單元測試覆蓋率和功能測試，以實現自動捕獲和監測架構指標和業務 KPI。最后，我們將看到架構重整，以使構建時間加快，部署包變小，同時更快地給工程師提供反饋。為了在這些領域取得成功，APM 將發揮重要作用。
DevOps 之自動化測試
DevOps 中的測試是必然是自動化測試，全員測試，產品經理，開發人員，測試人員，架構師等協同合作，使得測試覆蓋每個方面。而且當一天上線多次時，添加補丁或者更新功能，自動化測試是保證產品測試完全的最優選擇。不僅僅因為自動化測試比手動測試的速度快，它針對指定組件的所有歷史測試用例都能進行迭代測試。
DevOps 中的 QA(Quality Assurance) 更多的質量保證，不再只是一些細節問題的測試，而是回歸產品整體質量的保證。
DevOps 之協作開發
DevOps 中開發團隊之間協作，代碼提交和管理模式、測試機制、代碼的交付周期、反饋和監控體系方面都要顧到，開發不再只是埋頭寫代碼，還要為自己代碼質量負責，出 bug 了，運行緩慢了如果問題定位是代碼的原因，那這個坑就得自己填了。
DevOps 中由開發團隊完成交付工作，不像以前開發團隊和交付團隊是2個團隊，用各自習慣的工具，交付工作中使用的工具套件是開發流程中的工具，無需轉手，簡化開發測試人員的工作。
DevOps 之可視化運維
DevOps 中的一套成熟的運維系統包括什么？
自動化測試
批量配置基礎組件
監控，告警
數據可視化
協同合作
一套成熟的運維系統，能夠將應用、網絡、計算、存儲、虛擬化等資源的性能以及告警信息進行綜合分析，通過簡潔易懂的界面，直觀呈現業務健康水平。當出現故障時，能夠第一時間受到信息，從監控相關信息確定問題位置，縮小故障定位范圍，確定問題是在計算、應用還是網絡，進而明確問題職責，讓相應的開發運維迅速處理問題，沒有推脫責任之嫌。
OneAPM Cloud Insight 集監控、管理、計算、協作、可視化於一身，幫助所有 IT 公司，減少在系統監控上的人力和時間成本投入，讓運維工作更加高效、簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。
===========================================
http://blog.oneapm.com/apm-tech/760.html
DevOps工具包中合適的工具可以幫助你在企業內成功實施DevOps，增強敏捷發布過程和團隊協作。筆者想先聲明，DevOps不僅涉及工具，如果背后沒有合適的人員與文化，即使擁有最好的工具，也不能成功實施DevOps。不幸的是，沒有“文化”工具可供你使用，讓你能夠立刻在團隊之間培養協作和反饋。
合適的工具可以提供框架，幫助公司成功實施DevOps。你選擇的工具，應該鼓勵反饋，並防止進一步形成孤立。工具還應該幫助統一和協調團隊。確定采用的DevOps工具包，是實現DevOps目標和量化成功的關鍵第一步。雖然工具的特性集和解決方案是很重要的，也要確保重視工具組合起來的效果。無法整合的工具可能會需要過多的維護，成本，或產生沖突的信息。
在一個非常簡化的應用生命周期視圖中，筆者將過程划分為四個主要步驟：規划，設計，部署和維護。在每一個步驟中，都有可以增強這一環節的工具。同樣重要的是，這個過程不是一次性的，這是一個持續的循環。這種持續的反饋周期，是DevOps成功的必要基礎。
與其通過一系列的產品列表來選擇DevOps工具，你應該考慮自己的應用生命周期，根據特定的目標來做出選擇。
基礎
雖然有多款工具可以支持你的DevOps規划，但幾乎每一種規划都依靠相同的基礎：借助應用智能在雲中進行構建。如果沒有雲，自動化和敏捷性幾乎是不可能的——讓我們在雲的假設下繼續。
使用虛擬化支持，在雲中構建，你可以根據需求，適當調整，實現動態擴展的靈活性。雲的好處是成本與需求成線性比例，所以你只需支付自己使用的部分。
要有效管理DevOps環境，你需要聯合高管、開發人員與運維，並監測應用程序和終端用戶的性能。不同團隊和個人在一個控制台相互協作，並獲得相關應用智能的訪問權限，從而優化軟件戰略，對實現DevOps是至關重要的。
雲/基礎設施
Azure
AWS
Rackspace
Joyent
Cloud Foundry
虛擬化工具
VMware
Xen
VirtualBox
應用智能
AppDynamics
OneAPM
規划
開發一個新的應用，或更新現有的應用，都應該從規划開始。讓開發人員了解應用的商業目標可以鼓勵他們帶有目的地進行思考，同時開啟反饋循環。
同樣，重要的是，無論你最終選擇哪個工具，都應該能建立於你的應用基礎之上，或與之相整合。
數據庫
MongoDB
Cassandra
hBase
MySQL
PostgreSQL
Redis
搜索
Solr
ElasticSearch
Web服務器
NGINX
Apache
設計與架構
企業和開發人員經常犯的一個錯誤，就是在真空或孤立筒倉中設計應用程序。若沒有任何反饋機制，你只是在構建自己認為有用的功能。
其實，有各種各樣的工具和方法都可以優化這一階段的DevOps開發。現有應用的實時用戶監測和分析，可以有效判斷客戶的真正需求。它可能是一個沒有必要的功能或特性，或者只是因為太復雜而沒有被使用，或者有性能問題，無法正常工作。你可以監測哪些特性和功能使用得最為頻繁，哪些根本不使用。最重要的是，通過分析使用量和性能，你可以識別潛在的問題。
擴展
ActiveMQ
RabbitMQ
Memcached
Varnish
部署
配置管理工具，容器和自動化測試真正改變了開發格局。DevOps的流動性和快節奏是其基礎和優勢之一，但它也是一個挑戰，需要維持穩定的網絡訪問。 配置管理工具， 比如Puppet，Chef，和Ansible讓企業可以管理IT配置，通過模塊組件和自動化實施，從而確保持續、可靠、穩定的環境。它們使你能將基礎設施作為代碼。
容器
Docker
Kubernetes
持續集成
Jenkins
Travis CI
Circle CI
配置管理
Puppet
Chef
Ansible
維護
你的應用上線了，部署完成了，並不意味着你的工作就結束了。性能問題，停機時間，崩潰仍有可能困擾你的應用，進而影響業務。作為一個新的DevOps團隊，你需要做好運營工作。當有問題時，收到告警，進而找到問題的根源是至關重要的，可以確保積極、無縫的用戶體驗。
告警
OneAlert
PagerDuty
ServiceNow
VictorOps
BigPanda
日志記錄
Splunk
SumoLogic
Loggly
Logentries
DevOps是持續的，沒有明確的生命周期起點或終點。這一切都始於接受DevOps文化，建立雲和虛擬化的堅實基礎。除此之外，規划、設計、架構、實施，部署，維護和運行應用的生命周期是一個循環往復的過程。
DevOps環境太復雜和多變，很難通過人工流程管理；使用最傳統的方法監測，是無法跟上步伐的。為了有效地循環和往復，企業需要專為DevOps設計一個監測解決方案。