Гаворка, вядома, аб . Калі не ўдавацца ў дэталі, то 30 верасня і 1 кастрычніка мы правядзём канферэнцыю аб аб'яднанні працэсаў распрацоўкі, тэсціравання і эксплуатацыі, а калі ўдавацца - прашу пад кат.
У рамках DevOps-падыходу ўсе часткі тэхналагічнага развіцця праекту пераплецены паміж сабой, адбываюцца раўналежна і ўплываюць сябар на сябра. Асаблівую значнасць тут набывае стварэнне аўтаматызуемых працэсаў распрацоўкі, якія можна мяняць, мадэляваць і тэсціраваць у рэальным часе. Гэта дапамагае маментальна рэагаваць на змены ў рынку.
На канферэнцыі мы жадаем паказаць, як уплывае такі падыход на развіццё прадукта. Як забяспечваецца надзейнасць і адаптыўнасць сістэмы для кліента. Як DevOps мяняе структуру і падыход кампаніі да арганізацыі працоўнага працэсу.
Закуліссе
Нам важна ведаць не толькі, што робяць розныя кампаніі ў рамках DevOps-падыходу, але і разумець, навошта вось гэта вось усё. Таму ў склад Праграмнага камітэта мы паклікалі не проста экспертаў, а спецыялістаў, якія бачаць DevOps-дыскурс з розных пазіцый:
- senior-інжынераў;
- распрацоўшчыкаў;
- тымлідаў;
- CTO.
З аднаго боку, гэта стварае цяжкасці і канфлікты пры абмеркаванні заявак на даклады. Калі інжынеру цікавы разбор буйной аварыі, то распрацоўніку важней зразумець, як стварыць софт, які працуе ў аблоках і інфраструктурах. Але дамаўляючыся, мы ствараем такую праграму, якая будзе каштоўная і цікавая для ўсіх: ад інжынераў да CTO.
Задача нашай канферэнцыі не проста выбраць даклады похайповее, але прадставіць агульную карціну: як працуе DevOps-падыход на практыцы, на якія граблі можна нарвацца пры пераходзе да новых працэсаў. Пры гэтым мы выбудоўваем кантэнтную частку, спускаючыся ад бізнес-задачы да канкрэтных тэхналогій.
Секцыі канферэнцыі застануцца тымі ж, што і ў .
- Інфраструктурная платформа.
- Інфраструктура як код.
- Бесперапынная пастаўка.
- Зваротная сувязь.
- Архітэктура ў DevOps, DevOps для CTO.
- SRE-практыкі.
- Навучанне і кіраванне ведамі.
- Бяспека, DevSecOps.
- DevOps-трансфармацыя.
Call for Papers: якія даклады мы шукаем
Патэнцыйную аўдыторыю канферэнцыі мы ўмоўна падзялілі на пяць груп: інжынеры, распрацоўшчыкі, спецыялісты па бяспецы, тымліды і CTO. У кожнай групы свая матывацыя прыйсці на канферэнцыю. І, калі паглядзець на DevOps з гэтых пазіцыяў, можна зразумець, як сфакусаваць сваю тэму і дзе расставіць акцэнты.
Для інжынераў, якія займаюцца стварэннем інфраструктурнай платформы, важна разабрацца ў існуючых трэндах, зразумець, якія тэхналогіі зараз самыя прасунутыя. Ім будзе цікава азнаёміцца з рэальным досведам выкарыстання гэтых тэхналогій і абмяняцца меркаваннямі. Інжынер з задавальненнем выслухае даклад з разборам якой-небудзь хардкорнай аварыі, мы ў сваю чаргу такі даклад пастараемся падабраць і адшліфаваць.
Для распрацоўшчыкаў важна разабрацца з такім паняццем, як воблачнае роднае прыкладанне. Гэта значыць як трэба распрацоўваць софт, каб ён працаваў у аблоках і розных інфраструктурах. Распрацоўніку неабходна ўвесь час атрымліваць зваротную сувязь ад праграмнага забеспячэння. Тут мы жадаем пачуць кейсы аб тым, як кампаніі выбудоўваюць гэты працэс, як трэба маніторыць працаздольнасць ПА і як уладкованы ўвесь працэс пастаўкі.
Спецыялістам у галіне кібербяспекі важна разумець, як наладзіць працэс забеспячэння бяспекі такім чынам, каб ён не стопарыў працэсы распрацоўкі і змен усярэдзіне кампаній. Цікавыя будуць і тэмы аб патрабаваннях, якія DevOps прад'яўляе да такіх адмыслоўцаў.
Тымліды хочуць ведаць, як уладкованы працэс continuous delivery у іншых кампаніях. Якім шляхам кампаніі да гэтага ішлі, як выбудоўваліся працэсы распрацоўкі, забеспячэнні якасці ўсярэдзіне DevOps. Cloud native тымлідам таксама цікавы. А яшчэ – пытанні аб узаемадзеянні ўнутры каманды і паміж камандамі распрацоўшчыкаў і інжынераў.
Для Тэхнічны дырэктар самае галоўнае - разабрацца, як усе гэтыя працэсы злучыць і падбудаваць пад бізнес-патрэбы. Ён клапоціцца аб тым, каб прыкладанне было надзейным і для бізнэсу, і для кліента. І тут трэба разумець, якія тэхналогіі пад якія бізнес-задачы будуць працаваць, як пабудаваць працэс цалкам і г.д. CTO адказвае і за бюджэтаваньне. Напрыклад, ён павінен разумець, колькі трэба выдаткаваць грошай на перанавучанне адмыслоўцаў, каб яны маглі працаваць у DevOps.
Калі ў вас ёсць, што сказаць па гэтых падставах, не маўчыце, . Апошні тэрмін па Call for Papers – 20 жніўня. Чым раней заявіцеся, тым больш часу будзе на дапрацоўку дакладу і падрыхтоўку да выступу. Так што, не зацягвайце.
Ну а калі патрэбы выступаць публічна ў вас няма, проста і прыходзьце 30 верасня і 1 кастрычніка размаўляць з калегамі. Абяцаем, будзе цікава і натхняльна.
Як мы бачым DevOps
Каб дакладна разумець, што мы ўкладваем у паняцце DevOps, рэкамендую прачытаць (або перачытаць) мой даклад». Гуляючы па хвалях рынка, я назіраў, як трансфармуецца ўяўленне аб DevOps у розных па велічыні кампаніях: ад невялікага стартапа да транснацыянальных кампаній. Даклад пабудаваны на серыі пытанняў, адказваючы на іх, можна зразумець, ці рухаецца ваша кампанія да DevOps ці дзесьці ёсць праблемы.
DevOps - гэта складаная сістэма, у ёй павінны быць:
- Лічбавы прадукт.
- Бізнэс модулі, якія гэты лічбавы прадукт развіваюць.
- Прадуктовыя каманды, якія пішуць код.
- Практыкі Continuous Delivery.
- Платформы як сэрвіс.
- Інфраструктура як сэрвіс.
- Інфраструктура як код.
- Асобныя практыкі падтрымання надзейнасці, зашытыя ўнутры DevOps.
- Практыка зваротнай сувязі, якая апісвае ўсё гэта.
У канцы даклада ёсць схема, якая дае ўяўленне аб DevOps-сістэме ў кампаніі. Яна дазволіць убачыць, якія працэсы ў вашай кампаніі ўжо адладжаны, а якія толькі трэба будзе выбудоўваць.
Відэа даклада можна паглядзець .
А зараз будзе бонус: некалькіх відэа з РИТ++ 2019, якія датычацца найбольш агульных пытанняў DevOps-трансфармацыі.
Інфраструктура кампаніі як прадукт
Арцём Навуменка кіруе DevOps-камандай у Skyeng і клапоціцца аб развіцці інфраструктуры сваёй кампаніі. Ён распавёў, як інфраструктура ўплывае на бізнэс-працэсы ў SkyEng: як лічыць для яе ROI, якія метрыкі варта абраць для падліку і як працаваць над іх паляпшэннем.
На шляху да мікрасэрвісаў
Кампанія Nixys займаецца падтрымкай нагружаных web-праектаў і размеркаваных сістэм. Яе тэхнічны дырэктар Барыс Яршоў расказаў, як перавесці на сучасныя рэйкі праграмныя прадукты, распрацоўка якіх пачалася гадоў 5 таму (ці нават больш).
Як правіла, такія праекты - гэта асаблівы свет, дзе ёсць такія цёмныя і старажытныя куткі інфраструктуры, што пра іх не ведаюць цяпер дзеючыя інжынеры. А выбраныя некалі падыходы да архітэктуры і распрацоўкі састарэлі і не могуць забяспечыць бізнесу ранейшы тэмп развіцця і выпуску новых версій. У выніку кожны рэліз прадукта ператвараецца ў неверагодную прыгоду, дзе ўвесь час нешта адвальваецца, прычым у самым нечаканым месцы.
Кіраўнікі такіх праектаў непазбежна сутыкаюцца з неабходнасцю трансфармацыі ўсіх тэхналагічных працэсаў. У сваім дакладзе Барыс расказаў:
- як выбраць прыдатную для праекта архітэктуру і прывесці ў парадак інфраструктуру;
- якія прылады выкарыстоўваць і якія падводныя камяні сустракаюцца на шляхі да трасфармацыі;
- што рабіць далей?
Аўтаматызацыя рэлізаў ці як даставіць хутка і без болю
Аляксандр Караткоў - вядучы распрацоўшчык сістэмы CI / CD у ЦИАН. Ён расказаў пра інструменты аўтаматызацыі, якія дазволілі павысіць якасць і скараціць час дастаўкі кода ў прадакшн у 5 разоў. Але такіх вынікаў немагчыма было б дабіцца толькі адной аўтаматызацыяй, таму Аляксандр звярнуў увагу і на змены ў працэсах распрацоўкі.
Як аварыі дапамагаюць вучыцца?
Аляксей Цаглянцаў ужо 5 гадоў займаецца ўкараненнем DevOps і інфраструктурай у СКБ Контур. За тры гады ў яго кампаніі адбылося прыкладна 1000 факапаў рознай ступені эпічнасці. Сярод іх, напрыклад, 36% былі выкліканыя выкочваннем няякаснага рэлізу ў прадакшн, а 14% - працамі па абслугоўванні жалеза ў дата-цэнтры.
Атрымліваць такую дакладную інфармацыю аб аварыях дазваляе архіў справаздач (постмартэмы), якія інжынеры кампаніі вядуць ужо некалькі гадоў запар. Постмартэм піша дзяжурны інжынер, які першым адрэагаваў на сігнал аб аварыі і пачаў усё правіць. Навошта мучаць інжынераў, якія па начах ваююць з факапамі, напісаннем справаздач? Гэтыя дадзеныя дазваляюць убачыць карціну цалкам і рухаць інфраструктурную распрацоўку ў правільным напрамку.
У сваім выступе Аляксей падзяліўся, як напісаць сапраўды карысны постмортэм і як укараніць практыку такіх справаздач у буйной кампаніі. Калі любіце гісторыі пра тое, як нехта аблажаўся, паглядзіце відэа выступу.
Мы разумеем, што ваша бачанне DevOps можа не супадаць з нашымі ўяўленнямі. Будзе цікава даведацца, як вы бачыце DevOps-трансфармацыю. Падзяліцеся ў каментарах сваім вопытам і бачаннем гэтай тэмы.
Якія даклады мы ўжо прынялі ў праграму?
На гэтым тыдні Праграмны камітэт прыняў 4 даклады: аб бяспецы, інфраструктуры і SRE-практыках.
Мабыць, самая балючая тэма DevOps-трансфармацыі: як зрабіць так, каб рабяты з аддзела інфармацыйнай бяспекі не парушылі ўжо выбудаваныя сувязі паміж распрацоўкай, эксплуатацыяй і адміністраваннем. Некаторыя кампаніі абыходзяцца і без аддзела ИБ. Як у такім выпадку забяспечыць інфармацыйную бяспеку? Пра гэта Мона Архіпава з sudo.su. З яе даклада мы даведаемся:
- што і ад каго трэба абараняць;
- якія руцінныя працэсы бяспекі;
- як перасякаюцца працэсы ІТ і ИБ;
- што такое CIS CSC і як гэта ўкараніць;
- як і па якіх паказчыках праводзіць рэгулярныя праверкі ИБ.
Наступны даклад датычыцца развіцця інфраструктуры як кода. Зменшыць колькасць ручной руціны і не ператварыць увесь праект у хаос, ці магчыма гэта? На гэтае пытанне Максім Кастрыкін з Ixtens. У яго кампаніі выкарыстоўваюць Terraform для працы з AWS-інфраструктурай. Інструмент зручны, але пытанне ў тым, як пры ім выкарыстанні пазбегнуць з'яўленні велізарнай груды кода. Абслугоўванне такой спадчыны з кожным годам будзе абыходзіцца ўсё даражэй і даражэй.
Максім пакажа, як працуюць патэрны размяшчэння кода, накіраваныя на спрашчэнне аўтаматызацыі і развіцця.
Яшчэ адзін аб інфраструктуры пачуем ад Уладзіміра Рабава з Playkey. Тут гаворка пойдзе пра інфраструктурную платформу, і мы даведаемся:
- як зразумець, ці эфектыўна выкарыстоўваецца аб'ём сховішчы;
- як некалькі сотняў карыстачоў могуць атрымаць па 10 ТБ кантэнту, калі выкарыстоўваюцца ўсяго 20ТБ сховішчы;
- як сціснуць дадзеныя ў 5 разоў і прадастаўляць іх карыстальнікам у real-time;
- як налёту сінхранізаваць дадзеныя паміж некалькімі дата-цэнтрамі;
- як выключыць любы ўплыў карыстачоў сябар на сябра пры паслядоўным выкарыстанні адной віртуальнай машыны.
Сакрэт гэтай магіі – у тэхналогіі ZFS для FreeBSD і яе свежым форцы ZFS на Linux. Уладзімір падзеліцца кейс ад Playkey.
Мацвей Кукуй з Amixr.IO гатовы на прыкладах з жыцця , што такое SRE і як яно дапамагае будаваць надзейныя сістэмы. Amixr.IO прапускае інцыдэнты кліентаў праз свой бэкенд, дзясяткі дзяжурных каманд па ўсім свеце ўжо разабралі 150 тысяч выпадкаў. На канферэнцыі Мацвей падзеліцца статыстыкай і інсайтамі, якія яго кампанія назапасіла, вырашаючы праблемы кліентаў і аналізуючы факапы.
Яшчэ раз заклікаю не скнарнічаць і падзяліцца сваім досведам DevOps-самурая. Падавайце на даклад, і ў нас з вамі будзе 2,5 месяцы, каб падрыхтаваць выдатны выступ. Калі хочаце быць слухачом, на рассылку з абнаўленнямі праграмы і сур'ёзна задумайцеся аб заблагачасовым браніраванні білетаў, таму што бліжэй да дат канферэнцыі яны падаражэюць.
Крыніца: habr.com