Tôi giới thiệu với bạn hướng dẫn về DevOpsConf, một hội nghị năm nay có quy mô thiên hà. Theo nghĩa là chúng tôi đã cố gắng kết hợp một chương trình mạnh mẽ và cân bằng đến mức nhiều chuyên gia sẽ thích thú khi tham gia chương trình đó: nhà phát triển, quản trị viên hệ thống, kỹ sư cơ sở hạ tầng, QA, trưởng nhóm, trạm dịch vụ và nói chung là tất cả mọi người tham gia vào quá trình phát triển công nghệ quá trình.
Chúng tôi đề xuất đến thăm hai khu vực rộng lớn của vũ trụ DevOps: một khu vực có quy trình kinh doanh có thể thay đổi linh hoạt thông qua mã và khu vực còn lại có các công cụ. Nghĩa là, tại hội nghị của chúng tôi sẽ có hai luồng có sức mạnh ngang nhau về nội dung và đặc biệt là về số lượng báo cáo. Một phần tập trung vào việc sử dụng thực tế các công cụ và phần thứ hai tập trung vào các quy trình sử dụng các ví dụ về các vấn đề kinh doanh được coi là mã và được quản lý dưới dạng mã. Chúng tôi tin rằng công nghệ và quy trình được liên kết chặt chẽ và thể hiện điều này một cách có hệ thống với sự trợ giúp của các diễn giả làm việc trong các công ty làn sóng mới và chia sẻ con đường dẫn đến nhận thức mới về phát triển thông qua giải quyết vấn đề và vượt qua thử thách.
Nếu bạn muốn, một bản tóm tắt ngắn gọn về hướng dẫn của chúng tôi :
- Vào ngày 30 tháng 8, ngày đầu tiên của hội nghị, tại hội trường đầu tiên, chúng tôi sẽ xem xét XNUMX trường hợp kinh doanh.
- Tại hội trường thứ hai vào ngày đầu tiên, chúng tôi sẽ phân tích các giải pháp công cụ chuyên môn cao hơn. Mỗi báo cáo chứa đựng nhiều kinh nghiệm thực tế thú vị, tuy nhiên, không phải công ty nào cũng phù hợp.
- Ngược lại, vào ngày 1 tháng XNUMX, tại hội trường đầu tiên, chúng tôi nói nhiều hơn về công nghệ nhưng rộng hơn.
- Tại hội trường thứ hai vào ngày thứ hai, chúng tôi thảo luận về những nhiệm vụ cụ thể không phát sinh trong tất cả các dự án, chẳng hạn như trong một doanh nghiệp.
Nhưng tôi sẽ lưu ý ngay rằng sự phân chia như vậy hoàn toàn không có nghĩa là sự phân chia khán giả. Ngược lại, điều quan trọng là một kỹ sư phải hiểu các vấn đề kinh doanh, biết ý nghĩa việc mình đang làm và có kinh nghiệm thực tế. Và đối với trưởng nhóm hoặc trạm dịch vụ, tất nhiên, các trường hợp và kinh nghiệm của các công ty khác là quan trọng, nhưng đồng thời bạn cần hiểu rõ hoạt động nội bộ. Bên dưới phần cắt, tôi sẽ cho bạn biết chi tiết hơn về tất cả các chủ đề và giúp bạn lập kế hoạch du lịch chi tiết.
Hội nghị sẽ được tổ chức trong Không gian thông tin và chúng tôi gọi hai hội trường chính là “Trái tim vàng” - giống như con tàu trong “Hướng dẫn đến thiên hà của người đi nhờ xe”, sử dụng nguyên tắc khả năng di chuyển trong không gian và “Ở rìa của thiên hà”. Universe” - giống như một nhà hàng trong cùng một câu chuyện. Từ giờ trở đi tôi sẽ dùng những cái tên này để chỉ các bản nhạc. Báo cáo các điểm dừng trong khu vực thiên hà “Trái tim vàng” phù hợp hơn với nhóm khách du lịch chính, đây là những điểm tham quan không thể bỏ qua nếu bạn thích. “Ở rìa vũ trụ” có những đồ vật thú vị dành cho những du khách có kinh nghiệm. Rất ít người đến được đó, ngoại trừ những người dám đến đó với đôi mắt rực lửa xuyên qua các vành đai tiểu hành tinh.
Đồng thời, bạn có thể dễ dàng di chuyển từ phòng này sang phòng khác và bất cứ lúc nào bạn cũng sẽ tìm được chủ đề phù hợp với mình. Như tôi đã nói, chương trình rất cân bằng. Chúng tôi có nhiều báo cáo lớp hơn, nhưng bất đắc dĩ, Ủy ban Chương trình phải chuyển chúng sang hoặc hoãn lại cho đến hội nghị mùa xuân ở St. Petersburg, để không làm mất cân bằng và thực hiện ý tưởng ban đầu. Chương trình hội nghị cho phép bạn xem xét từng chủ đề đã lên kế hoạch (phân phối liên tục, cơ sở hạ tầng dưới dạng mã, chuyển đổi DevOps, thực hành SRE, bảo mật, nền tảng cơ sở hạ tầng) bằng các ví dụ khác nhau và từ các góc độ khác nhau.
Bây giờ hãy ngồi lại, con tàu thiên hà của chúng ta sắp đến điểm dừng.
“Trái tim vàng”, ngày 30/XNUMX
90 ngày đầu tiên làm CTO
Sẽ khai mạc hội nghị Leona lửa. về việc kế thừa các hệ thống cũ và những vấn đề thường xảy ra với chúng. Leon sẽ cho bạn biết làm thế nào trạm dịch vụ có thể hiểu được hệ thống kỹ thuật mà anh ấy bắt đầu làm việc. Đối với một giám đốc kỹ thuật trong một công ty hiện đại, việc quản lý quy trình DevOps là nhiệm vụ chính và Leon sẽ chỉ cho bạn một cách thú vị và hài hước Mối quan hệ giữa bộ phận kỹ thuật và kinh doanh theo quan điểm của SRT.
Những người mới bắt đầu và những người muốn trở thành một người chắc chắn nên đến với báo cáo này. Suy cho cùng, việc phát triển để trở thành giám đốc kỹ thuật trong công ty của bạn là một chuyện, và việc tái đảm nhận vai trò này là một chuyện khác; những màn nhào lộn trên không như vậy không phải ai cũng có được.
Khái niệm cơ bản về DevOps - tham gia dự án từ đầu
Следующий tiếp tục chủ đề, nhưng Andrey Yumashev (LitRes) sẽ xem xét vấn đề ít mang tính toàn cầu hơn một chút và trả lời các câu hỏi: bạn cần biết những điều cơ bản nào khi bắt đầu làm việc trong các nhóm khác nhau; cách phân tích chính xác phạm vi vấn đề; cách xây dựng kế hoạch hoạt động; cách tính KPI và khi nào nên dừng.
Tương lai của cơ sở hạ tầng dưới dạng mã
Tiếp theo chúng ta sẽ nghỉ giải lao để thảo luận về chủ đề cơ sở hạ tầng dưới dạng mã. Roman Boyko Kiến trúc sư giải pháp tại AWS tại DevOpsConf về công cụ mới Bộ công cụ phát triển đám mây AWS, cho phép bạn mô tả cơ sở hạ tầng bằng ngôn ngữ quen thuộc (Python, TypeScript, JavaScript, Java). Chúng ta sẽ trực tiếp tìm hiểu điều gì cho phép đám mây trở nên gần gũi hơn với nhà phát triển, cách bắt đầu sử dụng công cụ này và tạo các thành phần có thể tái sử dụng để quản lý cơ sở hạ tầng thuận tiện. Đối với những người tham gia hội nghị, đây là cơ hội tuyệt vời để nghe về những đổi mới trên thế giới bằng tiếng Nga và với mức độ chi tiết kỹ thuật phổ biến ở đây, nhưng không phải ở phương Tây.
Từ bản phát hành đến FastTrack
Sau bữa trưa, chúng ta sẽ quay lại vấn đề biến đổi trong vài giờ nữa. TRÊN Evgenia Fomenko Hãy cùng theo dõi quá trình chuyển đổi DevOps của MegaFon: bắt đầu từ giai đoạn họ cố gắng sử dụng các phương pháp truyền thống, chẳng hạn như KPI, vượt qua giai đoạn khi chưa có gì rõ ràng và bạn cần nghĩ ra những công cụ mới và thay đổi chính mình, cho đến khi quá trình được cơ cấu lại hoàn toàn. Đây là một trải nghiệm rất thú vị và đầy động lực cho doanh nghiệp, doanh nghiệp cũng có sự tham gia của các nhà thầu vào quá trình chuyển đổi DevOps, điều mà Evgeniy cũng sẽ nói đến.
Làm thế nào để trở thành một nhóm đa chức năng
У Mikhail Bizhan có nhiều kinh nghiệm trong việc thực hiện những thay đổi mang tính chuyển đổi trong nhóm. Giờ đây, Mikhail, với tư cách là lãnh đạo Nhóm Tăng tốc Raiffeisenbank, giúp các nhóm có chức năng chéo. trên của anh ấy Hãy nói về nỗi đau của việc thiếu các nhóm đa chức năng và tại sao những thách thức của một nhóm đa chức năng không chỉ dừng lại ở việc phát minh, chế tạo và triển khai.
thực hành SRE
Hơn nữa, chúng ta sẽ tìm thấy hai báo cáo dành riêng cho các hoạt động SRE đang có đà phát triển và chiếm một vị trí quan trọng trong toàn bộ quy trình DevOps.
Alexey Andreev từ Phòng thí nghiệm Prisma , tại sao một công ty khởi nghiệp cần thực hành SRE và tại sao nó lại mang lại hiệu quả.
Matvey Grigoriev từ Dodo Pizza một ví dụ về SRE trong một công ty lớn hơn đã vượt qua giai đoạn khởi nghiệp. Bản thân Matvey đã nói điều này về bản thân: một nhà phát triển .NET có kinh nghiệm và một SRE mới bắt đầu sẽ chia sẻ câu chuyện về quá trình chuyển đổi của một nhà phát triển, không chỉ một mà là cả một nhóm, sang cơ sở hạ tầng. Tại sao DevOps là con đường hợp lý cho nhà phát triển và điều gì sẽ xảy ra nếu bạn bắt đầu xem tất cả các playbook và tập lệnh bash Ansible của mình như một sản phẩm phần mềm chính thức và áp dụng các yêu cầu tương tự cho chúng, chúng ta sẽ thảo luận trong báo cáo của Matvey vào lúc 30:17 ngày 00 tháng XNUMX tại hội trường Golden Heart.
Hoàn thành chương trình ngày đầu tiên Daniil Tikhomirov, ai trong anh ấy đặt ra một câu hỏi quan trọng: Công nghệ liên quan thế nào đến sự hài lòng của người dùng. Giải quyết vấn đề “mọi thứ đều hoạt động nhưng người dùng không hài lòng”, MegaFon đi từ giám sát các hệ thống riêng lẻ, sau đó là máy chủ, ứng dụng sang giám sát dịch vụ qua con mắt của người dùng. Làm thế nào mà tất cả các chuyên gia kỹ thuật, khách hàng và nhà cung cấp bắt đầu tập trung vào các chỉ số KQI này, chúng ta sẽ tìm hiểu vào buổi tối của ngày đầu tiên của hội nghị. Và sau đó, chúng ta sẽ thảo luận về cơ sở hạ tầng và sự chuyển đổi trong bối cảnh thân mật tại bữa tiệc sau đó.
“Ở rìa vũ trụ”, ngày 30 tháng XNUMX
Ba báo cáo đầu tiên trong hội trường “Ở rìa vũ trụ” sẽ rất thú vị từ góc nhìn của các công cụ.
Maxim Kostrikin (Ixtens) các mẫu trong Terraform để chống lại sự hỗn loạn và thói quen trong các dự án lớn và dài hạn. Các nhà phát triển Terraform cung cấp các phương pháp thực hành tốt nhất khá thuận tiện để làm việc với cơ sở hạ tầng AWS, nhưng vẫn có một số sắc thái. Bằng cách sử dụng các ví dụ về mã, Maxim sẽ trình bày cách không biến thư mục có mã Terraform thành quả cầu tuyết mà sử dụng các mẫu để đơn giản hóa quá trình tự động hóa và phát triển hơn nữa.
Grigory Mikhalkin từ Lamoda “Tại sao chúng tôi phát triển toán tử Kubernetes và chúng tôi đã học được bài học gì từ nó?” sẽ giúp lấp đầy sự thiếu thông tin về cách triển khai cơ sở hạ tầng dưới dạng thực hành mã bằng Kubernetes. Ví dụ: bản thân Kubernetes chứa mô tả về các dịch vụ sử dụng tệp yaml, nhưng điều này không đủ cho tất cả các tác vụ. Quản lý cấp thấp yêu cầu người vận hành và bài nói chuyện này rất hữu ích nếu bạn muốn quản lý Kubernetes đúng cách.
Chủ đề của báo cáo tiếp theo là Hashicorp Vault - khá đặc biệt. Nhưng trên thực tế, công cụ này cần thiết ở bất cứ nơi nào bạn cần quản lý mật khẩu và có điểm chung là làm việc với các bí mật. Năm ngoái, Sergey Noskov đã kể về cách quản lý bí mật trong Avito với sự trợ giúp của Hashicorp Vault, hãy nhìn xem và đến yuri Shukin từ Tinkoff.ru để có thêm kinh nghiệm.
Taras Kotov (EPAM) nhiệm vụ thậm chí còn hiếm hơn là xây dựng cơ sở hạ tầng đám mây bao gồm cả đường trục của chính nó Mạng IP/MPLS. Nhưng trải nghiệm rất tuyệt và báo cáo rất khó hiểu, vì vậy nếu bạn hiểu nội dung của nó, hãy nhớ xem báo cáo này.
Buổi tối muộn chúng ta sẽ nói về quản lý cơ sở dữ liệu trong cơ sở hạ tầng đám mây. Kirill Melnichuk kinh nghiệm sử dụng Vitess khi làm việc với MySQL bên trong cụm Kubernetes. Một Vladimir Ryabov từ Playkey.net , cách làm việc với dữ liệu bên trong đám mây và cách sử dụng hợp lý dung lượng lưu trữ sẵn có.
“Trái tim vàng”, ngày 1 tháng XNUMX
Vào ngày 1 tháng XNUMX, mọi thứ sẽ ngược lại. Hội trường Golden Heart sẽ có đường đua thiên về công nghệ hơn. Vì vậy, đối với các kỹ sư đi qua “Trái tim vàng”, trước tiên chúng tôi mời bạn đi sâu vào các trường hợp kinh doanh và sau đó xem cách giải quyết những trường hợp này trong thực tế. Và các nhà quản lý, trước tiên, hãy nghĩ về các nhiệm vụ có thể thực hiện được, sau đó bắt đầu hiểu rõ hơn cách thực hiện điều này trong các công cụ và phần cứng.
Dưới mui xe của bộ lưu trữ đám mây lớn
Người nói đầu tiên Artemy Kapitula. Báo cáo của ông năm ngoái“Tôi nghĩ những người tham gia hội nghị gọi đây là bộ phim hay nhất do chiều sâu đáng kinh ngạc của câu chuyện. Thời gian này sẽ tiếp tục với các giải pháp của Mail.Ru Cloud Solutions về thiết kế lưu trữ và phân tích tiền lệ lỗi hệ thống. Lợi ích rõ ràng của báo cáo này đối với các nhà quản lý là Artemy không chỉ xem xét bản thân vấn đề kỹ thuật mà còn xem xét toàn bộ quá trình giải quyết nó. Những thứ kia. Bạn có thể hiểu cách quản lý toàn bộ quá trình này và áp dụng nó vào công ty của mình.
Triển khai phi tập trung đảo ngược
Egor Bugaenko Đây không phải là lần đầu tiên ông xuất hiện tại hội nghị; các báo cáo của ông thường chứa đựng những luận điểm gây tranh cãi, nhưng chúng khiến bạn phải suy nghĩ. Chúng tôi hy vọng rằng Cuộc nói chuyện của Egor về việc triển khai phi tập trung sẽ gây ra một cuộc thảo luận thú vị và quan trọng nhất là mang tính xây dựng.
Chúng ta lại ở trên mây
Alexey Vakhovlà sự kết hợp mạnh mẽ giữa các thành phần kinh doanh và công nghệ, điều này sẽ rất thú vị từ cả hai phía kỹ thuật và quản lý. Alexey sẽ cho bạn biết Uchi.ru hoạt động như thế nào Cơ sở hạ tầng Cloud Native: cách sử dụng Service Mesh, OpenTracing, Vault, ghi nhật ký tập trung và tổng SSO. Sau đó, lúc 15h, Alexey sẽ tổ chức , nơi mà tất cả những ai đến sẽ có thể tự tay chạm vào tất cả những nhạc cụ này.
Apache Kafka trong Avito: câu chuyện về ba lần tái sinh
Anatoly Soldatov tất nhiên, về cách Avito xây dựng Kafka như một dịch vụ sẽ được những người sử dụng Kafka quan tâm. Nhưng mặt khác, nó bộc lộ rất rõ quá trình tạo ra một dịch vụ nội bộ: cách thu thập các yêu cầu dịch vụ và mong muốn của đồng nghiệp, triển khai giao diện, xây dựng sự tương tác giữa các nhóm và tạo ra dịch vụ như một sản phẩm trong công ty. Từ quan điểm này, lịch sử một lần nữa lại hữu ích cho những người tham gia hội nghị rất khác nhau.
Hãy làm cho microservices nhẹ trở lại
Ở đây, có vẻ như mọi thứ đều rõ ràng ngay từ cái tên. Nhưng luận điểm đó Dmitry Sugrobov từ Leroy Merlin, ngay cả trong ủy ban chương trình cũng đã gây ra cuộc tranh luận sôi nổi. Nói một cách dễ hiểu, đây sẽ là cơ sở tốt để thảo luận về chủ đề những gì thường được coi là microservice, cách viết chúng, duy trì chúng, v.v.
CI/CD để quản lý cơ sở hạ tầng BareMetal
Báo cáo tiếp theo lại là hai trong một. Một mặt, Andrey Kvapil (WEDOS Internet, as) sẽ nói về việc quản lý cơ sở hạ tầng BareMetal, khá cụ thể, bởi vì mọi người hiện nay chủ yếu sử dụng đám mây và nếu họ nắm giữ phần cứng thì nó không ở quy mô lớn như vậy. Nhưng điều rất quan trọng là Andrey ứng dụng các kỹ thuật CI/CD để triển khai và quản lý cơ sở hạ tầng BareMetal, và từ quan điểm này, báo cáo sẽ được cả trưởng nhóm và kỹ sư quan tâm.
Tiếp tục chủ đề Serge Makarenko, đằng sau hậu trường của quá trình sử dụng nhiều lao động này Nền tảng Wargaming.
Container có thể an toàn?
Sẽ hoàn thành chương trình tại hội trường Trái Tim Vàng Alexander Khayorov tài liệu thảo luận về an ninh container. Alexander đã ở RIT++ về các vấn đề bảo mật của Helm và cách giải quyết nó, và lần này nó sẽ không giới hạn ở việc liệt kê các điểm yếu mà còn công cụ để cách ly hoàn toàn môi trường.
“Ở rìa vũ trụ”, ngày 1 tháng XNUMX
Sẽ bắt đầu Alexander Burtsev (BramaBrama) và một trong những giải pháp khả thi để tăng tốc trang web. Hãy nhìn vào việc thực hiện thành công năm phần chỉ tăng tốc nhờ các công cụ DevOps mà không cần viết lại mã. Bạn vẫn sẽ phải quyết định có nên viết lại mã hay không trong mỗi dự án, nhưng việc ghi nhớ kinh nghiệm đó luôn hữu ích.
DevOps trong 1C: Doanh nghiệp
Petr Gribanov từ công ty 1C vạch trần quan niệm sai lầm rằng không thể triển khai DevOps trong một doanh nghiệp lớn. Điều gì có thể phức tạp hơn nền tảng 1C: Enterprise, nhưng vì các phương pháp DevOps vẫn có thể áp dụng được ở đó nên tôi nghĩ huyền thoại sẽ không còn tồn tại.
DevOps trong phát triển tùy chỉnh
Anton Khlevitsky tiếp theo báo cáo của Evgeniy Fomenko , cách MegaFon xây dựng DevOps từ phía nhà thầu và xây dựng Triển khai liên tục, bao gồm cả hoạt động phát triển tùy chỉnh từ một số nhà cung cấp phần mềm.
Đưa DevOps vào DWH/BI
Một chủ đề không chuẩn nhưng lại thú vị dành cho những người tham gia khác nhau Vasily Kutsenko từ Gazprombank. Vasily sẽ chia sẻ lời khuyên thiết thực về cách phát triển văn hóa CNTT trong phát triển dữ liệu và áp dụng các phương pháp thực hành DevOps trong Data Warehous và BI, đồng thời sẽ cho bạn biết quy trình làm việc với dữ liệu khác nhau như thế nào và công cụ tự động hóa nào thực sự hữu ích trong bối cảnh làm việc với dữ liệu. dữ liệu.
Làm thế nào (bạn) sống mà không có bộ phận an ninh
Sau bữa trưa Mona Arkhipova (sudo.su) chúng tôi với những điều cơ bản DevSecOps và sẽ giải thích cách bạn có thể nhúng bảo mật như một quy trình vào quy trình phát triển của mình và ngừng sử dụng bộ phận bảo mật riêng biệt. Chủ đề này đang rất cấp bách và báo cáo sẽ rất hữu ích cho nhiều người.
Kiểm tra tải trong CI/CD của một giải pháp lớn
Bổ sung hoàn hảo cho chủ đề trước Vladimir Khonin từ MegaFon. Ở đây chúng ta sẽ nói về cách đưa chất lượng vào quy trình DevOps: cách sử dụng Cổng chất lượng, ghi lại các trường hợp khác nhau trong hệ thống và cách tích hợp tất cả vào quá trình phát triển. Báo cáo này đặc biệt phù hợp với những người làm việc với các hệ thống lớn, nhưng ngay cả khi bạn không làm việc với hóa đơn khổng lồ, bạn sẽ tìm thấy những khía cạnh thú vị cho riêng mình.
SDLC & Tuân thủ
Và chủ đề tiếp theo phù hợp hơn với các công ty lớn - cách đưa các giải pháp Tuân thủ và yêu cầu tiêu chuẩn vào quy trình. Ilya Mitrukov từ Trung tâm Công nghệ Deutsche Bank Đó tiêu chuẩn công việc có thể tương thích với DevOps.
Và vào cuối ngày Matvey Kukuy (Amixr.IO) số liệu thống kê và hiểu biết sâu sắc về cách hàng chục đội trên khắp thế giới đang làm nhiệm vụ, phân loại sự cố, tổ chức công việc và xây dựng hệ thống đáng tin cậy, đồng thời sẽ giải thích tất cả những điều đó liên quan đến SRE như thế nào.
Bây giờ tôi thậm chí còn ghen tị với bạn một chút, bởi vì cuộc hành trình xuyên qua bạn chỉ cần phải làm vậy. Bạn có thể tạo kế hoạch cá nhân của riêng mình và tận hưởng cách các báo cáo sẽ bổ sung cho nhau một cách hữu cơ, nhưng rất có thể, tôi, giống như bất kỳ hướng dẫn nào, sẽ không có thời gian để xem xét cẩn thận xung quanh.
Nhân tiện, ngoài chương trình chính, có thể nói, chúng tôi còn có một địa điểm cắm trại - một phòng họp, trong đó chính những người tham gia có thể tổ chức một cuộc gặp gỡ nhỏ, hội thảo, lớp học chính và thảo luận về các vấn đề cấp bách trong một khung cảnh thân mật. bất kỳ người tham gia nào cũng có thể và bất kỳ người tham gia nào cũng có thể đóng vai trò là ủy ban chương trình và bỏ phiếu cho các cuộc gặp mặt khác. Định dạng này đã chứng minh tính hiệu quả của nó, đặc biệt là về mặt kết nối mạng, vì vậy hãy xem xét kỹ hơn lịch trình và trong suốt hội nghị, hãy theo dõi các thông báo về các cuộc gặp gỡ mới trong .
Hẹn gặp lại bạn trong thiên hà DevOpsConf 2019!
Nguồn: www.habr.com