開發人員如何重新編碼？

如果您查看其他組織，那麼爲什麼開發人員會花很多時間在其他事情上？因爲，當您開始與必須進行手動監視的開發人員交談時，他們可能不需要很多額外的工作。他們引入了另一個必須學習的庫，然後花時間弄清楚它是如何工作的。然後，他們還必須嘗試找出將數據發送到哪裏。然後弄清楚，“我如何訪問數據？我也只訪問開發中或生產後期的數據嗎？”

使用Dynatrace，這些都是您不再需要解決的所有事情，因爲這是開箱即用的。沒有手動代碼檢測，數據會自動發送到Dynatrace，會自動進行分析，然後我們對該數據瞭解很多。我們知道這些數據來自何處。我們知道它來自Blake，因爲他在下午兩點通過Jenkins將此構建部署到了這個環境中，然後又部署到了這個環境中。讓我比較這兩個版本。然後讓我向布雷克發送一條帶有結果的Slack消息。現在情況已得到解決。

從您的角度來看，雲工具如何使開發人員的生活更輕鬆？我越來越多地聽到有關開發人員將更多時間花在與編碼無關的任務上或將大量時間花在手動監視上的故事。

我們正在朝着實現自主雲的方向發展，這意味着我們的ACE團隊正在提供平臺中的所有工具，從而減輕了開發人員的所有痛苦，並將其作爲自助服務提供給他們。

因此，這意味着如果開發人員在他們想要部署的工件中，他們想要獲得反饋，他們基本上只是說：“這是我的工件將其放入容器註冊表中。” 然後將其拿起，並通過我稱之爲專心的管道進行部署，以我們採用它的方式，部署它並運行有意義的測試的方式來討論，這意味着我們知道要更改的代碼，並且僅運行有意義的測試。

接下來，我們正在研究KPI，因此我們正在研究SLI（服務水平指標）和SLO（服務水平目標）驗證。因此，我們弄清楚了這段代碼的性能，與以前的版本相比性能如何以及與之前的版本相比。然後，我們通過Slack將這些糾正性反饋提供給開發人員。如果有明確的問題，我們將自動打開JIRA門票。基本上，在故障單中，爲他們提供了所需的所有數據，因爲所有數據都在我們自動監控的地方。

在內部，我們在Dynatrace上使用Dynatrace，因此實質上，我們希望用戶使用Dynatrace時使用Dynatrace。這意味着要對開發，質量檢查，暫存和生產進行儀器檢測。不僅將其用於監視，而且還用於生產工作負載以及在我們的生產前測試中應用該工作負載。因爲如果您運行測試，則要運行儘可能接近生產的測試。這些是我們可以做的。

我們可以將數據作爲自助服務提供。因此，我總是說我們有很多很棒的數據，但是最重要的是，如果我們能夠在正確的時間以他們選擇的工具將正確的數據提供給正確的人，以便他們做出下一個正確的決定。我們可以通過Slack提供數據。我們可以創建JIRA門票。我們可以將其推送到他們的IDE中。我們可以爲開發人員做很多事情。

我們要做的是通過自助服務，在他們願意使用的工具中爲他們提供所需的數據。這對他們有很大幫助，因爲他們不必學習其他工具。他們不必配置任何額外的東西。這不是他們需要做的額外步驟。數據就在那裏。大多數情況是完全自動發生的，例如監視。此外，代碼分析和性能特徵會自動發生。

繼續我的故事，當我說開發人員將某些東西上傳到註冊表中並進行部署時，如果效果很好，它會自動升級到下一階段，我們可能會進行更多性能測試，然後開發者反饋，“嘿，這是可靠且出色的代碼。” 因此，如果您願意，我們可以投入生產。只需單擊即可。“好吧，讓我們把它推出。您是想將它發佈給所有人，還是想先將它發佈給一個小的測試小組，以獲得一些反饋？”

在過去，如果幸運的話，部署可能每月一次進行，現在您可以聽到 Citrix的Nestor A. Zapata這樣的用戶的故事， 他們每天可以使用Dynatrace進行多次部署。

究竟！之所以花費這麼長時間，是因爲當我們開始進行DevOps轉型時，這對於我們的組織也是如此。我們首先在覈心Dynatrace軟件平臺上進行了此操作，但是我們還有許多其他團隊正在構建其他軟件。他們都建立了自己的資料和管道。他們都想出瞭如何進行連續交付的方式，並且都花了很多時間來確保這些工具正常工作，這沒有意義，因爲像您一樣，這些開發人員表示他們希望構建真正的新功能，而不是處理管線還活着。

因此，當我們說我們需要提供圍繞Dynatrace構建的平臺時。當我們提供Dynatrace軟件平臺時，我們需要爲所有其他開發團隊做同樣的事情。因此，我們需要爲他們提供一個平臺，使他們變得非常自治，可以在我們的雲平臺上交付軟件。一切都必須是自助服務，以便他們實際上可以專注於提供新功能和新價值。

許多IT經理都在努力擺脫技術債務。他們還試圖最大程度地減少停機時間，並減少追蹤問題的時間。雲工具在這方面提供了即時幫助。

我們還通過Keptn解決了一個客戶問題。多虧詹金斯（Jenkins），它纔出現在大約10至15年前，並且徹底改變了CI，許多人還把它用於CD。我在與Jenkins合作的公司中看到的是，他們開始於某些項目，建立了管道，並且爲他們工作。然後，接下來的事情發生了，他們複製了該管道，並根據需要對其進行了修改。然後，接下來的事情發生了，他們複製了該管道並根據需要對其進行了修改。因此，您最終得到10到15到100多個不同的管道，每個人都必須單獨維護它。

在這些管道中，這是基本的。這是邏輯定律。這是您必須繼續工作的所有編碼。這也是消磨開發人員編寫代碼熱情的一部分時間。這是我們使用Keptn解決的問題：不再有管道代碼。一切都是聲明性的。這意味着您不必處理要在腳本中定義的腳本，您要在哪個階段執行該腳本，爲哪個工具執行哪個工作，以及對輸出做什麼。Keptn是事件驅動的。它有一種自發的方法，可以通過部署，測試，評估和升級，通過管道中的意見來提升工件。它使開發人員可以抽出時間去做他們真正喜歡的事情。您將如何描述NoOps？

NoOps是一種心態。這就是我們所做的一切。在我們所做的每一件事中，我們都在考慮可能會出問題的地方，以及如何通過自動化避免這種情況的發生。那麼我的代碼更改或生產中的配置更改可能會出什麼問題，這些錯誤通常會導致Ops中的某人修復某些問題？我如何一開始就避免這種情況？如何構建更多測試來阻止錯誤的代碼更改？如何建立自動化的自我修復功能以自動回滾而不是讓某人做某事？

所以NoOps是一種心態。這個想法是，作爲開發人員，我只需要考慮以下幾點。如何在系統中建立彈性？關鍵指標是否可以告訴我我是否健康？然後根據這些指標，確定下一步該做什麼。我要放大還是縮小或回滾？最後，這意味着我要減少傳統的運營工作量。這就是爲什麼NoOps是一種心態。

仍然有很多人負責基礎架構和操作，但是由於自動化，我們使大多數事情實現了自動化，從而使問題永遠不會在生產中結束，因爲我們在流程的早期就停止了不良代碼更改。如果有問題要解決，我們希望儘可能自動地修復這些問題。

最後，我認爲Thomas Reisenbichler很好地說明了NoOps是一種心態，這意味着組織中的每個人都必須考慮我現在正在採取的措施可能會出什麼問題以及如何使它的修復自動化？

對於那些不熟悉零客戶的人，您將如何形容？是心態嗎？

不，客戶零意味着我們是我們自己的客戶。我們在Dynatrace之前先使用Dynatrace。因此，我們正在使用最新版本來監視我們的所有環境，然後再將其發佈給客戶。這就是爲什麼我們零客戶。我們是內部第一批使用最新版本，最新功能的公司，並且向產品團隊提供反饋。

正如Thomas Reisenbichler昨天說的那樣，Dynatrace ACE團隊啓發並要求了我們現在在Dynatrace平臺中看到的許多功能。我們正在交付管道中使用Dynatrace，就像我們希望客戶使用它一樣，但是此功能不能很好地完成其工作，“我們需要這個和這個。”

幾年前，他們說我們需要產品中的日誌分析。昨天我們在談論堆轉儲功能。這些都是零客戶所經歷的所有事情。我們想使用我們的產品，然後再使用第一個客戶。這就是爲什麼它是零顧客。

太好了，在其他許多公司中，我也看不到使用這種方法！

顯然，我們很幸運，該產品Dynatrace是解決了開發過程中許多問題的產品。

我想這取決於您作爲組織提供的產品類型以及如何儘早使用該產品。我敢肯定，大多數公司正在開發的軟件是可以在將其展示給客戶之前嘗試在內部使用的軟件。

從趨勢和未來的角度來看，在未來的道路上，有哪些事情可以激發您使開發人員的生活更加輕鬆？

如果您還記得昨天在談論圖片故事時的類比。我認爲我們需要做出的類比是，我們需要像拍攝照片一樣簡單，通過增強圖像的應用程序運行它，然後進行部署並獲得反饋。交付軟件必須變得非常簡單。編寫一些代碼，然後通過管道運行它，使我可以警惕不良代碼，然後就如何使其變得更好提出建議。然後自動將其交付給我的用戶，他們給了我反饋。

它必須像在Instagram上發佈內容一樣簡單。我認爲這是我未來五年的目標。

因此，軟件的抽象層仍然必須保留一種簡單的心態嗎？

是的，我們都知道世界上缺少開發人員。因此，這意味着爲了使我們能夠加入更多的開發人員，我認爲我們還需要使其變得更容易。您不能像我們一樣訓練對所有事情都有很深知識的軟件架構師。我們還需要考慮如何爲沒有軟件工程背景的新手提供幫助，以便他們能夠輕鬆開發自助軟件或以不費力的自助服務方式交付價值，而又不會讓他們搞砸一切。因此，它需要簡單易行，但必須具有故障保護功能。

相關文章