當然，我們正在談論的是 。 如果你不講細節，那麼30月1日和XNUMX月XNUMX日我們將召開開發、測試和營運流程結合的會議，如果你講細節，請在cat下。
在 DevOps 方法中，專案技術開發的所有部分都是相互交織、並行發生並相互影響的。 這裡特別重要的是創建可以即時更改、模擬和測試的自動化開發流程。 這有助於您立即響應市場變化。
在會議上，我們想展示這種方法如何影響產品開發。 如何確保系統對客戶的可靠性和適應性。 DevOps 如何改變公司的結構和組織工作流程的方法。
幕後
對我們來說，重要的是不僅要了解不同的公司在 DevOps 方法框架內正在做什麼，還要了解為什麼要這樣做。 因此，我們不僅邀請了專家加入程序委員會，也邀請了從不同立場看待 DevOps 論述的專家：
- 高級工程師；
- 開發商；
- 團隊領導；
- 首席技術官。
一方面，這在討論報告請求時造成了困難和衝突。 如果工程師有興趣分析重大事故，那麼開發人員更重要的是了解如何建立在雲端和基礎設施中運行的軟體。 但透過達成一致，我們創建了一個對每個人都有價值且有趣的計劃：從工程師到首席技術長。
我們會議的目標不僅僅是選擇最炒作的報告，而是展示整體情況：DevOps 方法在實踐中如何運作，在轉向新流程時可能會遇到什麼樣的麻煩。 同時，我們建立內容部分，從業務問題深入具體技術。
會議部分將保持不變 .
- 基礎設施平台。
- 基礎設施即代碼。
- 持續交付。
- 聯繫我們。
- DevOps 中的架構、CTO 的 DevOps。
- SRE 實踐。
- 培訓和知識管理。
- 安全、DevSecOps。
- DevOps 轉型。
徵文：我們正在尋找什麼樣的報告
我們有條件地將會議的潛在受眾分為五組：工程師、開發人員、安全專家、團隊負責人和 CTO。 每個小組都有自己參加會議的動機。 而且，如果您從這些立場來看 DevOps，您就可以了解如何聚焦您的主題以及重點在哪裡。
對工程師來說， 對於正在創建基礎設施平台的人來說，了解現有趨勢、了解哪些技術現在是最先進的非常重要。 他們將有興趣了解使用這些技術的現實經驗並交換意見。 工程師會很樂意聽一份分析一些嚴重事故的報告，我們也會盡力選擇和完善這樣的報告。
對於開發者 理解這樣一個概念很重要 雲端原生應用程式。 也就是說，如何開發軟體以使其在雲端和各種基礎設施中運作。 開發人員需要不斷收到軟體的回饋。 在這裡，我們希望聽到有關公司如何建立此流程、如何監控軟體效能以及整個交付流程如何運作的案例。
網路安全專家 了解如何設定安全流程非常重要，這樣它就不會阻礙公司內部的開發和變更流程。 關於 DevOps 對此類專家的要求的主題也很有趣。
團隊領導想知道，其他公司的持續交付流程如何運作。 公司採取了什麼途徑來實現這一目標，他們如何在 DevOps 中建立開發和品質保證流程。 團隊領導也對雲端原生感興趣。 還有關於團隊內部以及開發和工程團隊之間互動的問題。
為 技術長 最重要的是弄清楚如何連接所有這些流程並根據業務需求進行調整。 他確保該應用程式對於企業和客戶來說都是可靠的。 這裡你需要了解哪些技術適用於哪些業務任務，如何建立整個流程等。 CTO 也負責預算。 例如，他必須了解需要花多少錢來重新培訓專家，以便他們能夠在 DevOps 中工作。
如果您對這些事情有話要說，請不要保持沉默， 。 徵文截止日期為20月XNUMX日。 您註冊越早，您完成報告和準備簡報的時間就越多。 所以，不要拖延。
好吧，如果你不需要公開講話，就 30月1日和XNUMX月XNUMX日過來和同事交流。 我們保證這將是有趣且鼓舞人心的。
我們如何看待 DevOps
為了準確理解 DevOps 的含義，我建議閱讀（或重新閱讀）我的報告“」 走過市場的浪潮，我觀察到DevOps的概念是如何在不同規模的公司中轉變的：從小型新創公司到跨國公司。 該報告基於一系列問題，透過回答這些問題，您可以了解您的公司是否正在向 DevOps 邁進，或者是否存在問題。
DevOps是一個複雜的系統，它必須包括：
- 數碼產品。
- 開發此數位產品的業務模組。
- 編寫程式碼的產品團隊。
- 持續交付實踐。
- 平台即服務。
- 基礎設施即服務。
- 基礎設施即代碼。
- DevOps 中內建的維護可靠性的單獨實踐。
- 描述這一切的回饋實踐。
報告最後有一張圖表，展示了該公司的 DevOps 系統。 它可以讓您看到公司中的哪些流程已經簡化，哪些流程尚未建立。
您可以觀看報告視頻 .
現在還有一個獎勵： RIT++ 2019 的幾個視頻，涉及 DevOps 轉型的最常見問題。
公司基礎設施作為產品
Artyom Naumenko 領導 Skyeng 的 DevOps 團隊，負責公司基礎設施的開發。 他講述了基礎設施如何影響 SkyEng 的業務流程：如何計算投資回報率、應選擇哪些指標進行計算以及如何改善這些指標。
邁向微服務之路
Nixys 公司為繁忙的網路專案和分散式系統提供支援。 其技術總監 Boris Ershov 講述如何將 5 年前（甚至更早）開始開發的軟體產品轉移到現代平台。
一般來說，這類專案是一個特殊的世界，基礎設施中存在一些黑暗而古老的角落，目前的工程師對此一無所知。 而且曾經選擇的架構和開發方法已經過時，無法為業務提供相同的開發和新版本發布的速度。 結果，每一次產品發布都變成了一次令人難以置信的冒險，其中不斷有東西掉落，而且是在最意想不到的地方。
此類專案的管理者不可避免地需要改造所有技術流程。 鮑里斯在報告中說：
- 如何為專案選擇正確的架構並整理基礎架構；
- 使用哪些工具以及在轉型過程中遇到哪些陷阱；
- 接下來做什麼。
發布自動化或如何快速、輕鬆地交付
Alexander Korotkov 是 CIAN 的 CI/CD 系統的主要開發人員。 他談到自動化工具可以提高品質並將程式碼交付生產的時間縮短 5 倍。 但這樣的成果僅靠自動化是無法達成的，因此Alexander也關注開發流程的改變。
意外事故如何幫助你學習？
Alexey Kirpichnikov 已經在 SKB Kontur 實施 DevOps 和基礎設施 5 年了。 在三年的時間裡，他的公司發生了大約 1000 起不同程度的史詩般的假事件。 例如，其中 36% 是由於將低品質版本投入生產所造成的，14% 是由資料中心的硬體維護工作造成的。
公司工程師連續幾年維護的報告檔案（事後分析）使得獲得有關事故的準確資訊成為可能。 驗屍報告由值班工程師撰寫，他第一個響應緊急信號並開始修復一切。 為什麼要透過寫報告來折磨那些在晚上與 facap 作鬥爭的工程師呢？ 這些數據使您能夠了解全局並推動基礎設施發展朝著正確的方向發展。
Alexey在演講中分享如何寫出真正有用的事後分析報告，以及如何在大公司實施此類報告的實踐。 如果您喜歡某人如何搞砸的故事，請觀看表演影片。
我們理解您對 DevOps 的願景可能與我們的不同。 了解您如何看待 DevOps 轉型將會很有趣。 在評論中分享您對此主題的經驗和願景。
我們已經接受了哪些報告進入該計劃？
本週，計劃委員會通過了 4 份報告：關於安全、基礎設施和 SRE 實踐。
也許 DevOps 轉型中最痛苦的話題是：如何確保資訊安全部門的人員不會破壞開發、營運和管理之間已經建立的連結。 有些公司沒有資訊安全部門進行管理。 這種情況下如何確保資訊安全呢？ 關於它 來自 sudo.su 的莫娜·阿爾希波娃。 從她的報告中我們了解到：
- 需要保護什麼、免受誰的保護；
- 常規安全流程有哪些？
- IT 和資訊安全流程如何交叉；
- 什麼是 CIS CSC 以及如何實施；
- 如何以及透過哪些指標進行定期資訊安全檢查。
下一份報告涉及基礎設施即程式碼的開發。 減少手動例行工作量，並且不讓整個專案變得混亂，這可能嗎？ 對於這個問題 來自 Ixtens 的馬克西姆·科斯特里金 (Maxim Kostrikin)。 他的公司使用 Terraform 用於使用 AWS 基礎架構。 該工具很方便，但問題是如何避免在使用它時創建巨大的程式碼區塊。 維護這樣的遺產將變得越來越昂貴。
Maxim 將展示程式碼放置模式如何運作，旨在簡化自動化和開發。
其他 我們將聽到有關基礎設施的信息 Playkey 的弗拉基米爾·裡亞博夫。 這裡我們來講一下基礎設施平台，我們將學習：
- 如何了解儲存空間是否有效利用；
- 如果僅使用 10 TB 的儲存空間，數百個使用者如何能夠接收 20 TB 的內容；
- 如何將資料壓縮5倍並即時提供給使用者；
- 如何在多個資料中心之間即時同步資料；
- 如何在順序使用一台虛擬機器時消除使用者之間的影響。
這個魔法的秘密就是技術 適用於 FreeBSD 的 ZFS 和它的新鮮叉子 Linux上的ZFS。 Vladimir 將分享 Playkey 的案例。
來自 Amixr.IO 的 Matvey Kukuy 準備好生活中的例子 ， 發生了什麼事 SRE 以及它如何幫助建立可靠的系統。 Amixr.IO 透過其後端傳遞客戶事件；全球數十個值班團隊已處理了 150 萬個案例。 在會議上，Matvey 將分享他的公司透過解決客戶問題和分析失敗而累積的統計數據和見解。
我再次敦促您不要貪婪，分享您作為 DevOps 武士的經驗。 服務 為了一份報告，你和我將有 2,5 個月的時間來準備一篇精彩的演講。 如果你想成為一名傾聽者， 閱讀包含節目更新的時事通訊，並認真考慮提前預訂門票，因為臨近會議日期，門票會變得更加昂貴。
來源： www.habr.com