Tất nhiên, chúng ta đang nói về . Nếu bạn không đi sâu vào chi tiết, thì vào ngày 30 tháng 1 và ngày XNUMX tháng XNUMX, chúng tôi sẽ tổ chức một hội nghị về việc kết hợp các quá trình phát triển, thử nghiệm và vận hành, còn nếu bạn đi sâu vào chi tiết thì hãy theo dõi mèo.
Trong cách tiếp cận DevOps, tất cả các phần trong quá trình phát triển công nghệ của dự án đều gắn kết với nhau, diễn ra song song và ảnh hưởng lẫn nhau. Điều đặc biệt quan trọng ở đây là việc tạo ra các quy trình phát triển tự động có thể thay đổi, mô phỏng và thử nghiệm trong thời gian thực. Điều này giúp bạn phản ứng ngay lập tức với những thay đổi trên thị trường.
Tại hội nghị, chúng tôi muốn chỉ ra cách tiếp cận này ảnh hưởng đến việc phát triển sản phẩm. Độ tin cậy và khả năng thích ứng của hệ thống đối với khách hàng được đảm bảo như thế nào. DevOps đang thay đổi cấu trúc và cách tiếp cận của một công ty trong việc tổ chức quy trình làm việc của mình như thế nào.
đằng sau hậu trường
Điều quan trọng là chúng ta không chỉ phải biết các công ty khác nhau đang làm gì trong khuôn khổ phương pháp DevOps mà còn phải hiểu lý do tại sao tất cả những điều này lại được thực hiện. Do đó, chúng tôi đã mời không chỉ các chuyên gia tham gia Ủy ban Chương trình mà cả các chuyên gia xem diễn ngôn DevOps từ các vị trí khác nhau:
- kỹ sư cao cấp;
- nhà phát triển;
- trưởng nhóm;
- CTO.
Một mặt, điều này tạo ra những khó khăn, mâu thuẫn khi thảo luận về yêu cầu báo cáo. Nếu một kỹ sư quan tâm đến việc phân tích một vụ tai nạn lớn thì điều quan trọng hơn là nhà phát triển phải hiểu cách tạo ra phần mềm hoạt động trên đám mây và cơ sở hạ tầng. Nhưng bằng cách đồng ý, chúng tôi tạo ra một chương trình có giá trị và thú vị đối với tất cả mọi người: từ kỹ sư đến CTO.
Mục tiêu của hội nghị của chúng tôi không chỉ là chọn ra những báo cáo cường điệu nhất mà còn trình bày bức tranh tổng thể: cách tiếp cận DevOps hoạt động trong thực tế, loại cào mà bạn có thể gặp phải khi chuyển sang các quy trình mới. Đồng thời, chúng tôi xây dựng phần nội dung, đi từ bài toán kinh doanh đến công nghệ cụ thể.
Các phần hội nghị sẽ vẫn giữ nguyên như trong .
- Nền tảng cơ sở hạ tầng.
- Cơ sở hạ tầng như mã.
- Giao hàng liên tục.
- Phản hồi.
- Kiến trúc trong DevOps, DevOps cho CTO.
- thực hành SRE.
- Đào tạo và quản lý kiến thức.
- Bảo mật, DevSecOps.
- Chuyển đổi DevOps.
Kêu gọi giấy tờ: chúng tôi đang tìm kiếm loại báo cáo nào
Chúng tôi chia khán giả tiềm năng của hội nghị thành năm nhóm một cách có điều kiện: kỹ sư, nhà phát triển, chuyên gia bảo mật, trưởng nhóm và CTO. Mỗi nhóm đều có động lực riêng để đến hội nghị. Và, nếu bạn nhìn vào DevOps từ những vị trí này, bạn có thể hiểu cách tập trung vào chủ đề của mình và nơi cần nhấn mạnh.
Đối với các kỹ sư, Những người đang tạo ra nền tảng cơ sở hạ tầng, điều quan trọng là phải hiểu các xu hướng hiện có, hiểu công nghệ nào hiện nay là tiên tiến nhất. Họ sẽ quan tâm đến việc tìm hiểu về trải nghiệm thực tế trong việc sử dụng các công nghệ này và trao đổi ý kiến. Một kỹ sư sẽ rất vui khi nghe một báo cáo phân tích một số vụ tai nạn nghiêm trọng nào đó, và đến lượt chúng tôi, sẽ cố gắng lựa chọn và đánh bóng một báo cáo như vậy.
Cho các nhà phát triển điều quan trọng là phải hiểu một khái niệm như ứng dụng gốc trên nền tảng đám mây. Đó là cách phát triển phần mềm để nó hoạt động trên đám mây và các cơ sở hạ tầng khác nhau. Nhà phát triển cần liên tục nhận được phản hồi từ phần mềm. Ở đây chúng tôi muốn nghe các trường hợp về cách các công ty xây dựng quy trình này, cách giám sát hiệu suất phần mềm và cách hoạt động của toàn bộ quy trình phân phối.
Chuyên gia an ninh mạng Điều quan trọng là phải hiểu cách thiết lập quy trình bảo mật để nó không cản trở quá trình phát triển và thay đổi trong công ty. Các chủ đề về yêu cầu mà DevOps đặt ra đối với những chuyên gia như vậy cũng sẽ rất thú vị.
Trưởng nhóm muốn biếtQuá trình giao hàng liên tục diễn ra như thế nào ở các công ty khác. Các công ty đã đi theo con đường nào để đạt được điều này, họ đã xây dựng các quy trình phát triển và đảm bảo chất lượng trong DevOps như thế nào. Trưởng nhóm cũng quan tâm đến Cloud Native. Và cả những câu hỏi về sự tương tác trong nhóm cũng như giữa các nhóm phát triển và kỹ thuật.
vì CTO điều quan trọng nhất là tìm ra cách kết nối tất cả các quy trình này và điều chỉnh chúng theo nhu cầu kinh doanh. Ông đảm bảo rằng ứng dụng này đáng tin cậy cho cả doanh nghiệp và khách hàng. Và ở đây bạn cần hiểu công nghệ nào sẽ hoạt động cho nhiệm vụ kinh doanh nào, cách xây dựng toàn bộ quy trình, v.v. CTO cũng chịu trách nhiệm lập ngân sách. Ví dụ, anh ta phải hiểu cần phải chi bao nhiêu tiền cho việc đào tạo lại các chuyên gia để họ có thể làm việc trong DevOps.
Nếu bạn có điều gì muốn nói về những vấn đề này, đừng im lặng, . Hạn chót để kêu gọi giấy tờ là ngày 20 tháng XNUMX. Bạn đăng ký càng sớm thì bạn càng có nhiều thời gian để hoàn thiện báo cáo và chuẩn bị cho bài thuyết trình của mình. Vì vậy, đừng trì hoãn.
Chà, nếu bạn không có nhu cầu nói chuyện công khai, chỉ cần và đến vào ngày 30/1 và XNUMX/XNUMX để giao lưu với đồng nghiệp. Chúng tôi hứa nó sẽ thú vị và đầy cảm hứng.
Cách chúng tôi nhìn nhận DevOps
Để hiểu chính xác ý nghĩa của DevOps, tôi khuyên bạn nên đọc (hoặc đọc lại) báo cáo của mình “" Đi qua những làn sóng của thị trường, tôi quan sát thấy ý tưởng DevOps đang biến đổi như thế nào ở các công ty có quy mô khác nhau: từ một công ty khởi nghiệp nhỏ đến các công ty đa quốc gia. Báo cáo được xây dựng dựa trên một loạt câu hỏi, bằng cách trả lời chúng, bạn có thể hiểu liệu công ty của bạn đang hướng tới DevOps hay liệu có vấn đề gì đó ở đâu đó hay không.
DevOps là một hệ thống phức tạp, nó phải bao gồm:
- Sản phẩm kỹ thuật số.
- Các mô-đun kinh doanh phát triển sản phẩm kỹ thuật số này.
- Nhóm sản phẩm viết mã.
- Thực hành giao hàng liên tục.
- Nền tảng như một dịch vụ.
- Cơ sở hạ tầng như một dịch vụ.
- Cơ sở hạ tầng như mã.
- Các biện pháp thực hành riêng biệt để duy trì độ tin cậy, được tích hợp trong DevOps.
- Một thực hành phản hồi mô tả tất cả.
Cuối báo cáo có sơ đồ đưa ra ý tưởng về hệ thống DevOps trong công ty. Nó sẽ cho phép bạn xem quy trình nào trong công ty của bạn đã được sắp xếp hợp lý và quy trình nào vẫn chưa được xây dựng.
Bạn có thể xem video báo cáo .
Và bây giờ sẽ có một phần thưởng: một số video từ RIT++ 2019 đề cập đến các vấn đề chung nhất về chuyển đổi DevOps.
Cơ sở hạ tầng của công ty như một sản phẩm
Artyom Naumenko lãnh đạo nhóm DevOps tại Skyeng và đảm nhiệm việc phát triển cơ sở hạ tầng của công ty mình. Ông cho biết cơ sở hạ tầng ảnh hưởng như thế nào đến quy trình kinh doanh tại SkyEng: cách tính ROI cho nó, nên chọn số liệu nào để tính toán và cách làm việc để cải thiện chúng.
Trên đường đến microservice
Công ty Nixys cung cấp hỗ trợ cho các dự án web bận rộn và hệ thống phân tán. Giám đốc kỹ thuật của nó, Boris Ershov, đã cho biết cách dịch các sản phẩm phần mềm, quá trình phát triển bắt đầu từ 5 năm trước (hoặc thậm chí hơn), sang nền tảng hiện đại.
Theo quy định, những dự án như vậy là một thế giới đặc biệt, nơi có những góc tối và cổ kính của cơ sở hạ tầng mà các kỹ sư hiện tại không biết về chúng. Và các phương pháp tiếp cận kiến trúc và phát triển từng được chọn đã lỗi thời và không thể cung cấp cho doanh nghiệp tốc độ phát triển và phát hành phiên bản mới như cũ. Kết quả là, mỗi lần phát hành sản phẩm đều biến thành một cuộc phiêu lưu đáng kinh ngạc, nơi thứ gì đó liên tục rơi ra và ở nơi không ngờ nhất.
Người quản lý các dự án như vậy chắc chắn phải đối mặt với nhu cầu chuyển đổi tất cả các quy trình công nghệ. Trong báo cáo của mình, Boris nói:
- làm thế nào để chọn kiến trúc phù hợp cho dự án và sắp xếp cơ sở hạ tầng vào trật tự;
- nên sử dụng những công cụ nào và những cạm bẫy nào sẽ gặp phải trên con đường chuyển đổi;
- phải làm gì tiếp theo.
Tự động hóa các bản phát hành hoặc cách phân phối nhanh chóng và dễ dàng
Alexander Korotkov là nhà phát triển hàng đầu về hệ thống CI/CD tại CIAN. Ông nói về các công cụ tự động hóa giúp cải thiện chất lượng và giảm thời gian đưa mã vào sản xuất tới 5 lần. Nhưng những kết quả như vậy không thể đạt được chỉ bằng tự động hóa, vì vậy Alexander cũng chú ý đến những thay đổi trong quá trình phát triển.
Tai nạn giúp bạn học như thế nào?
Alexey Kirpichnikov đã triển khai DevOps và cơ sở hạ tầng tại SKB Kontur được 5 năm. Trong suốt ba năm, khoảng 1000 fakaps ở các mức độ hoành tráng khác nhau đã xảy ra trong công ty của anh ấy. Ví dụ, trong số đó, 36% là do đưa bản phát hành chất lượng thấp vào sản xuất và 14% là do công việc bảo trì phần cứng trong trung tâm dữ liệu.
Một kho lưu trữ các báo cáo (khám nghiệm tử thi) mà các kỹ sư của công ty đã duy trì trong nhiều năm liên tiếp giúp có thể thu được thông tin chính xác như vậy về các vụ tai nạn. Bản khám nghiệm tử thi được viết bởi kỹ sư trực ban, người đầu tiên phản ứng với tín hiệu khẩn cấp và bắt đầu khắc phục mọi thứ. Tại sao lại hành hạ những kỹ sư đang phải vật lộn với các khuôn mặt bằng cách viết báo cáo vào ban đêm? Dữ liệu này cho phép bạn nhìn thấy toàn cảnh và đưa việc phát triển cơ sở hạ tầng đi đúng hướng.
Trong bài phát biểu của mình, Alexey đã chia sẻ cách viết một bản khám nghiệm tử thi thực sự hữu ích và cách triển khai việc thực hành các báo cáo đó trong một công ty lớn. Nếu bạn thích những câu chuyện về việc ai đó đã mắc sai lầm như thế nào, hãy xem video về màn trình diễn.
Chúng tôi hiểu rằng tầm nhìn của bạn về DevOps có thể không giống với tầm nhìn của chúng tôi. Sẽ rất thú vị khi biết bạn nhìn nhận sự chuyển đổi DevOps như thế nào. Chia sẻ kinh nghiệm và tầm nhìn của bạn về chủ đề này trong phần bình luận.
Những báo cáo nào chúng tôi đã chấp nhận vào chương trình?
Tuần này, Ủy ban Chương trình đã thông qua 4 báo cáo: về an ninh, cơ sở hạ tầng và thực tiễn SRE.
Có lẽ chủ đề đau đầu nhất của quá trình chuyển đổi DevOps: làm thế nào để đảm bảo rằng những người từ bộ phận bảo mật thông tin không phá hủy các kết nối đã được xây dựng giữa phát triển, vận hành và quản trị. Một số công ty quản lý không có bộ phận bảo mật thông tin. Làm thế nào để đảm bảo an toàn thông tin trong trường hợp này? Về nó Mona Arkhipova từ sudo.su. Từ báo cáo của cô ấy, chúng tôi biết được:
- cái gì cần được bảo vệ và khỏi ai;
- các quy trình bảo mật thông thường là gì;
- cách thức các quy trình bảo mật thông tin và CNTT giao nhau;
- CIS CSC là gì và cách triển khai nó;
- làm thế nào và bằng những chỉ số nào để tiến hành kiểm tra an ninh thông tin thường xuyên.
Báo cáo tiếp theo liên quan đến việc phát triển cơ sở hạ tầng dưới dạng mã. Giảm lượng công việc thủ công và không biến toàn bộ dự án trở nên hỗn loạn, liệu điều này có khả thi? Đối với câu hỏi này Maxim Kostrikin từ Ixtens. Công ty của ông sử dụng Terraform để làm việc với cơ sở hạ tầng AWS. Công cụ này rất tiện lợi nhưng câu hỏi đặt ra là làm thế nào để tránh tạo ra một khối mã khổng lồ khi sử dụng nó. Việc duy trì một di sản như vậy sẽ ngày càng trở nên tốn kém hơn mỗi năm.
Maxim sẽ chỉ ra cách hoạt động của các mẫu vị trí mã, nhằm đơn giản hóa quá trình tự động hóa và phát triển.
Nữa chúng ta sẽ nghe về cơ sở hạ tầng từ Vladimir Ryabov từ Playkey. Ở đây chúng ta sẽ nói về nền tảng cơ sở hạ tầng và chúng ta sẽ tìm hiểu:
- làm thế nào để biết liệu không gian lưu trữ có đang được sử dụng hiệu quả hay không;
- làm thế nào hàng trăm người dùng có thể nhận được 10 TB nội dung nếu chỉ sử dụng 20 TB dung lượng lưu trữ;
- cách nén dữ liệu 5 lần và cung cấp cho người dùng theo thời gian thực;
- cách đồng bộ hóa dữ liệu nhanh chóng giữa một số trung tâm dữ liệu;
- cách loại bỏ mọi ảnh hưởng của người dùng lên nhau khi sử dụng tuần tự một máy ảo.
Bí mật của phép thuật này là công nghệ ZFS cho FreeBSD và cái nĩa mới của nó ZFS trên Linux. Vladimir sẽ chia sẻ các trường hợp từ Playkey.
Matvey Kukuy từ Amixr.IO sẵn sàng với những ví dụ từ cuộc sống , Gì SRE và cách nó giúp xây dựng các hệ thống đáng tin cậy. Amixr.IO chuyển các sự cố của khách hàng thông qua chương trình phụ trợ của nó; hàng chục nhóm trực trên khắp thế giới đã xử lý 150 nghìn trường hợp. Tại hội nghị, Matvey sẽ chia sẻ những số liệu thống kê và hiểu biết sâu sắc mà công ty của ông đã tích lũy được bằng cách giải quyết các vấn đề của khách hàng và phân tích những thất bại.
Một lần nữa tôi mong bạn đừng tham lam và hãy chia sẻ kinh nghiệm của mình với tư cách là một samurai DevOps. Phục vụ cho một báo cáo, bạn và tôi sẽ có 2,5 tháng để chuẩn bị một bài phát biểu xuất sắc. Nếu bạn muốn trở thành người nghe, đến bản tin có thông tin cập nhật về chương trình và suy nghĩ nghiêm túc về việc đặt vé trước thời hạn, vì chúng sẽ trở nên đắt hơn khi gần đến ngày hội nghị.
Nguồn: www.habr.com