Web系統的性能問題會影響企業的各項業務。
- 漏洞太多，運營團隊就只能疲於奔命。
- 缺少吸引力, 產品團隊則會受困於用戶留存率。
- 改不完的BUG, 開發團隊就沒時間進行新功能開發。
- 業務人員的效率跟着提升不上去。
- 技術經理不能清楚證明團隊所做的努力是否合理。
類似的情形常常出現。
有什麼方法可以避免這些風險呢? 工慾善其事必先利其器，我們需要引入一些趁手的工具，在項目開發的各個階段。
規劃工具
大部分軟件項目/產品都要先進行設計和規劃、並且持續跟蹤開發進度。規劃工具跨越整個生命週期, 在今天的軟件工程中，項目規劃就是一個項目的開始。就像是合理的養貓(Herd Cats), 或者是阻止給犛牛剃毛(Yak Shaving)。 最常用的是Jira ，或者根據自身情況選擇其他工具。
Herd Cats，養貓, 不同的軟件開發團隊, 就像養貓一樣, 非常難以管理; 幾乎不可能組織起來。
Yak Shaving，給犛牛剃毛，是一個編程術語，用來描述項目中看似無窮無盡的一系列小任務，必須完成這些小任務才能將項目推進到下一階段。
版本控制工具
持有小黃鴨(rubber duck)才能修改代碼的時代早已過去; 代碼的版本控制是每個團隊首先需要解決的問題。 即使是小型團隊、甚至是單人團隊, 版本控制都是必要的, 有句話說的好: “無版本、不編程！”
比較成熟的工具包括 Git, SVN, Mercurial 等等。 當然現在Git是優先選擇。
Git的安裝和使用, 請參考: https://blog.csdn.net/renfufei/article/details/41647875
測試工具
使用最廣泛的是 Selenium 測試工具. 使用Robot Framework 進行部署時, 可以使用通用測試自動化設置進行驗收測試。 它提供了一種強大的方式來斷言應用程序是否有效，併爲需求清單提供了良好的健全性檢查。
CI/CD工具
CI, Continuous integration, 持續集成
CD, Continuous delivery, 持續交付
參考: What is CI/CD?
隨着軟件開發方式的改變，軟件的發佈方式自熱也跟着發展。 爲了促進更快的發佈週期，團隊想要更頻繁地快速發佈軟件，則需要 CI/CD管道的方式。 這代表了持續集成和持續交付的綜合實踐。 Jenkins, Travis, 和 CircleCI 都是流行的CI/CD工具。
配置工具
配置工具的基本目標, 是有效管理大規模的機器設備(infrastructure)。 另外還有一些目標, 包括儘量減少工程師/系統管理員的人工干預，降低配置分佈式系統的複雜性。常用工具有 Ansible, 以及 Chef, Puppet, 以及 Salt。
監控工具
監控領域的工具, 又多又雜, 而且一直在努力發展和迭代。
早期的監控工具, 只在系統發佈時檢查服務器參數，並將這些參數用作系統運行狀況的指標。
服務器的健康狀況保持，與用戶體驗之間存在相關性。杯具在於，這種方式下發生的問題比實際檢測的要多。
如今，隨着瀏覽器、通信協議和其他方面的發展，這種模式發生了變化。可以爲瀏覽器設置代理(agent)來記錄用戶的體驗。
這些年在日誌管理、預警、遙測以及報告等領域投入了大量精力。其中一些是有效的, 記錄安全事件, 有意義的警報, 資源使用量都是具備價值的跟蹤數據, 但前提是有一個清晰的策略來伴隨用戶體驗的整個鏈路. 有一些工具, 比如 Zabbix, Nagios, 以及 Prometheus 被廣泛使用, 但都沒能解決實際用戶體驗的監控。
只購買這些軟件並不能緩解性能問題。 我們還需要採取各種措施，但這需要勇氣、專注、和不懈的堅持。Web系統性能調優是一件很嚴肅的事情, 需要付出很多努力, 還需要嚴格遵守紀律。當然, 這項工作對團隊的回報也是巨大的!
請記住 —— 性能問題的關鍵點是人, 也就是我們的用戶。
我們致力於更高的系統性能, 提供可靠的數字用戶體驗。 有很多方法可用於實現這一目標, 比如 Plumbr 。 喜歡的朋友可以註冊: http://app.plumbr.io/signup
原文鏈接: https://plumbr.io/blog/devops/tools-for-software-engineering-teams
原文日期: 2018年12月19日
翻譯日期: 2019年01月14日
翻譯人員: 鐵錨 - https://blog.csdn.net/renfufei