關於devops有一些常見的誤解，在這裡做一下簡單的整理和討論。
這種思維相當常見，自動化確實在devops中非常的重要。正如推動devops運動的標誌性事件之一的flickr的每日10+的部署的經驗來說，也提到了automation的重要性，「如果只有一件事情能做，那就做自動化」的類似共享也有提及，所以自動化的作用不言而喻。
自動化提高了生產效率，減低了手工操作的失誤率，消除了多個部門協調和溝通的制約因素，可以同時降低處理時間以及等待時間，而且有實實在在的總多工具的支援，在整個devops實踐中起到非常重要的作用。
但是這並不是全部，devops包含了people/process/technology/culture等諸多因素，作為一種最佳實踐的方**的組合，工具的自動化是其中的一部分，但不是全部。
在很多專案devops實踐中，原本運維在做的事情都工具化和自動化了，所以在很多人看來devops的作用之一就是為了砸運維的飯碗的。他們的理解就是devops是通過自動化承擔了原本運維作的很多事情。確實，很多時候devops實踐中會讓dev承擔很多**部署等的責任，但是這並不意味著不再需要運維了，相反，實施了devops之後的團隊會發現開發和運維的緊密連線是以往從未有過的，正確地來說，是解放了運維。
所有的這一切，其實都是在精益在軟體開發全生命領域的實踐體現，進行了很好devops實踐後，浪費之一的等待將會得到很大的改善，很多運維服務通過自動化變成了自助服務，降低了等待時間，極大地提高了效率。
devops在很多開源專案中推行地很好，而且很多devops用到的工具本身都是開源的。但是這並不意味著devops只適合於開源專案。就像不能說精益只能實踐於製造業是一樣的，devops作為一種綜合的方**，它適合於開源和閉源的專案，這並沒有特別大的區別。
我們能看到很多devops在初創公司成功的例子，相比而言傳統的大型的公司的比例似乎並沒有那麼多。其實這跟devops的關聯並不一定有這麼大，並不是每一家公司都能成為百年老店經久不衰。根據統計：2023年的500強公司的87%已經消失。缺乏創新的能力以及改變的魄力，企業的衰敗像人類的生老病死一樣難以改變。
而且這一速度仍然在加劇，2023年 500強的公司平均壽命為61年，而現在只有18年。而devops只是諸多變革方式中的一種，無論是初創公司還是大型傳統公司，使用devops獲得成功的都不在少數。所以，devops是一種能力，放在那裡，用或不用，你有選擇的自由。
傳統公司問題重重，而那些獨角獸公司看起來卻風光無限，amazon據說能夠每天部署上萬次。而且好像他們生來就具有devops能力一樣。而實際上，獨角獸公司作為從眾多初創公司中脫穎而出的一群，其他所有公司碰到的陣痛，他們也一樣未曾落下。
時間公司
事件2023年
amazon
在2023年之前一直使用obidos系統交付，問題重重難以為繼
2023年
對其ror系統進行逐步重構並替代該系統，耗時多年
2023年
ipo後六個月，在部署上吃盡苦頭，凍結兩個月功能，徹底檢修環境/部署和架構
2023年
基礎框架近乎崩潰，**部署日益危險，員工不停救火。展開改革後才改變狀況
好漢打掉牙或血吞，曾經的勇氣和魄力，換來的是現在的一時風光無限，自我改變和革新才是一切的根本。
關於測試 運維及devops的一些想法
最近倆年，devops比較火，但是實踐起來，各個公司卻都有各個公司的難處。有些公司因為包袱比較重轉型困難，有些因為資金不充足無法招到有具體實踐能力的人，也一直處於口號狀態，而有些初創的中小型公司因為比較隨意，也沒做具體的規劃，搞到後期也是一團亂糟糟。一直覺得，我們應該把開發當做客戶，而所有測試運維負...
關於git的一些錯誤解決方法。
最近在研究git在eclipse中的使用。出現了很多問題。特寫下該文章來幫助像我一樣的git新手。問題 non fast forward 的出現原因在於 git倉庫中已經有一部分 所以它不允許你直接把你的 覆蓋上去。於是你有2個選擇方式 1，強推，即利用強覆蓋方式用你本地的 替代git倉庫內的內容 ...
關於一些誤解黑盒測試想法的論述
關於一些誤解黑盒測試想法的論述 之前分別寫了一些白盒測試 黑盒測試 回歸測試 自動化測試的一些基本的東西，這期就重點說說白盒測試和黑盒測試的不同 一般軟體開發人員和測試人員對白盒測試和黑盒測試的感念都有一定的認識，但認為是編 所做的測試是白盒測試，黑盒測試不用編寫 這其實是一種誤解。黑盒測試，它是通...