Наскоро посетих DevOpsForum 2019, организиран от Logrocon. На тази конференция участниците се опитваха да намерят решения и нови инструменти за ефективна комуникация между бизнеса и специалистите по разработка и информационни технологии.
Конференцията беше успешна: имаше наистина много полезни доклади, интересни формати на презентации и много взаимодействия с лекторите. И особено важно е, че никой не се опита да ми продаде нещо, което напоследък е често срещано сред лекторите на големи конференции.
Съкращение от изявленията на Райфайзенбанк, Алфастраховане, опитът на Манго Телефон при внедряване на автоматизация и други подробности под кат.
Казвам се Яна, работя като тестировчик, занимавам се с автоматизация, както и с DevOps и обожавам да посещавам конференции и митапи. През последните две години присъствах на конференции на Олег Бунин (HighLoad++, TeamLead Conf), на събитията Jug (Heisenbug, JPoint), на TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Първото нещо, за което обръщам внимание, е програмата на конференцията. В по-малка степен гледам на това, за какво ще е докладът, а в по-голяма — на говорителя. Дори докладът да се окаже много технологичен и интересен, не е факт, че ще можеш да приложиш някои добри практики от него в своята компания. И тогава ти трябва говорител.
Светлина в края на пайплайна в Райфайзенбанк
Обикновено провеждам лов за интересни говорители в кулоарите. На DevOpsForum 2019 в полезен за мен попада докладчикът от Райфайзенбанк — Михаил Бижан. По време на изказването си той разказа как постепенно въвеждат своите екипи в DevOps, защо им е необходимо това и как да продадат на бизнеса идеята за DevOps трансформация. В общи линии, говореше за това как да видиш светлината в края на пайплайна.
Михаил Бижан, директор по автоматизация в Райфайзенбанк
В момента в компанията им няма "истински DevOps". Тоест, той е истински, но не във всички екипи. При внедряване на DevOps, те разчитат на готовността на екипите както от гледна точка на конкретни инженери, така и на потребностите на продукта и зрялостта на платформата, върху която е построен този продукт. Миша разказа как да обясниш на бизнеса защо е необходим DevOps.
В банковския сектор има няколко фактора за растеж: цената на услугите и разширяването на клиентската база. Увеличаването на цените не е много добър фактор, но растежът на клиентската база е точно обратното. Ако конкурентите пуснат обективно страхотен продукт, всички клиенти отиват там, след което с времето пазарът се изравнява. Затова навлизането на нови продукти на пазара и скоростта на това навлизане са основните неща, на които банките се ориентират. точно заради това е необходим DevOps и бизнесът го разбира.
Следващото важно наблюдение: DevOps не винаги намалява времето до пазара. DevOps не може да работи сам, той е само част от процеса на създаване и изпускане на продукт на пазара от разработването до продукцията (от кода до клиента). Но всичко, което е преди кода, няма пряко отношение към DevOps. Тоест, маркетолозите могат години наред да проучват пазара и цял живот да настигат конкуренцията. Необходимо е бързо да се разбере какво е нужно на клиента и да се планира реализирането на определена функция — точно това често липсва, за да работи DevOps и компанията да постигне целта си. Затова, на първо място, в Райффайзенбанк се договориха с бизнеса, че трябва да се научат как да използват DevOps. Автоматизацията заради автоматизацията не е голямо решение за борба за нови клиенти.
Общо взето, Миша смята, че DevOps трябва да бъде внедрен, но разумно. И трябва да бъдеш готов за това, че в началото на трансформацията производителността на екипа ще намалява, те ще печелят по-малко пари, но след това това ще бъде оправдано.
Автоматизация на тестването в "Манго Телеком"
Един интересен доклад, който направи Егор Маслов от „Манго Телеком“. Презентацията се наричаше „Автоматизация на пълния цикъл на тестване в SCRUM екип“. Егор смята, че DevOps е създаден именно за SCRUM, но внедряването на DevOps в SCRUM екип е доста проблематично. Причината е, че SCRUM екипът все време бърза, няма време да се отклони от нововъведенията и да пренастройва процеса. Проблемът е също, че SCRUM не предполага създаването на подекипи (екип тестировчици, екип разработчици и т.н.). Освен това, за автоматизация на съществуващия процес е нужна документация, а в SCRUM документацията често липсва напълно - „продуктът е по-важен от някакви писания“.
След преминаването на SCRUM, тестировчиците започнаха да се консултират с разработчиците как да тестват функционалностите. Постепенно обемът на функционалността нарастваше, документацията липсваше и те започнаха да откриват много бъгове в функционалността, която нямаше покритие с тестове и вече не беше ясно кой и кога я е тествал. С две думи - разпад и хаос. Решиха да преминат към автоматизация на тестването. Но и тогава се случи пълен провал. Те привлечеха аутсорс специалисти за автоматизация, които пишеха на непознат за штатните тестировчици стек. Фреймуъркът за автотестовете разбира се работеше, но след като аутсорсерите си заминаха, той преживя две седмици. Следващата опит за внедряване на автоматизирано тестване започна с идеята, че всичко трябва да се строи вътре в компанията, с техни сили (правилен вектор: нараствайте експертизата вътре), в рамките на SCRUM, и по време на процеса да се създава документация. Стекът за автоматизация трябва да бъде равен на стека на продукта (тук направо се съгласявам, не тествате проекта на JavaScript с нещо друго). В края на спринта те организираха демо на това как работи автотестът, с участието на целия екип (полезно). Така се повишаваше ангажираността на всички членове на екипа в процеса на автоматизация, както и доверието в автотестовете и шанса, че този автотест наистина ще се използва (а не ще бъде коментиран след месец поради постоянни провали).
На DevOpsForum 2019 имаше отворен микрофон — отдавна познат и, според мене, полезен формат на излагања. Шеташ, слушаш предавања, а потоа одлучуваш дека е редно да дискутираш за некоја тема или проблем, да споделиш релевантно искуство во решавањето на задачи.
Забележав дека организаторите створиле поток на кратки предавања. Секоја презентација трае не повеќе од 10 минути, потоа следат прашања. На тој начин може веднаш да се покријат многу теми и да им се упатат прашања на говорниците кои те интересираат.
Меѓу предавањата прошетав по штандовите на партнерите на конференцијата и зеде/победи многу работи. Ох, обожавам рекламни материјали!
Кругла маса и прашања за DevOps со директорот за развој во Алфаосигурување.
Вишенката на тортата DevOpsForum 2019 за мене беше часовната пленарна сесија со експерти од DevOps. Беа поканети четири учесници на сесијата, кои требаше да ја погледнат DevOps од различни агли: Антон Исанин (Алфаосигурување, директор за развој), Наиля Замашкина (Финтек Лаб, оперативен директор), Олег Егоракин (Ростелеком, Agile-тренер) и Антон Мартьянов (независен експерт, кој ја гледаше DevOps од деловниот аспект).
Експертите седнаа блиску до народот и почнаа да се расправаат: цел час учесниците од салата поставуваа свои прашања, а експертите одговараа. Понекогаш се јавуваа вистински дебати. Прашањата беа најразлични, на пример: дали воопшто се потребни DevOps-инженери, зошто не може да се одгледаат од системски администратори, треба ли сите да предложат DevOps, во што е неговата вредност и така натаму.
Потоа, разговарав со Антон Исаниным лично. Разговаравме за потребата да се носи културата на DevOps во секој дом и откривањето на темната страна на DevOps трансформацијата.
Да предположим, че всички се събраха и решиха, че DevOps е нужен както на продукта, така и на бизнеса и екипа. Започнаха да го внедряват. Всичко сработи. Вдигнахме дух. DevOps ни направи по-близки до клиента, сега бързо можем да изпълняваме всички негови желания. В крайна сметка имаме голямо звено Ops с строги регламенти и изисквания, и то непрекъснато генерира дефекти за продукта, създава купища заявки. Освен това всички дефекти идват със статус „спешен“, дори когато клиентът неочаквано реши да оцвети бутона в жълто вместо в зелено. Проектът расте, увеличава се броят на релизите и съответно броят на дефектите и недоразуменията с новата функционалност от страна на клиентите. Ops наема още 10 души, за да успява да отчита дефектите, докато разработката наема още 15, за да затваря тези дефекти. И вместо да внедряват нови функции, екипът работи с безкрайни тикети, обяснявайки функционалността на потребителите и на поддръжката заедно. В крайна сметка както Ops, така и разработката са заети, но клиентът и бизнесът са недоволни: новите функции затъват. Оказва се, че DevOps сякаш го има, но и сякаш го няма.
Относно необходимостта да се внедри DevOps, Антон категорично заяви, че това пряко зависи от мащабите на бизнеса. Ако обслужването на един клиент годишно носи на компанията милиард — DevOps не е нужен (при условие, че не трябва да внедрявате нови промени на този клиент редовно). Всичко е наред. Но ако бизнесът расте, и броят на клиентите нараства, тогава е нужно да се отговори на това. Обикновено в компанията няма добър Ops от самото начало. Първо разработваме продукта, а след това осъзнаваме, че за да работи продуктът, трябва да се следим за сървъри, да следим доставките. Тогава се появява Ops. Остава да разберем, че Ops, като отделно звено, ще започне да поставя куп бариери за разработката и всички доставки ще започнат да буксуват. Тоест в този случай културата DevOps вече е актуална, само че трябва да не забравяме за нейната тъмна страна.
Източник: habr.com
