Моли Струви е Lead Site Reliability Engineer в Kenna Security. В момента работата й се върти около Elasticsearch и MySQL бази данни, като на помощ идват Ruby и Ansible. Запознайте се с нейния опит в разработката и трудностите при избора на технология, която наистина върши чудеса!

Каква е работата на един Lead Site Reliability Engineer?

Преди да задълбоча върху естеството на работата, искам да поясня дефиницията на позицията ми. Site Reliability Engineer (накратко “SRE”) е професия, която може да бъде най-различна в зависимост от компанията. Екипът на SRE в Kenna е група от разработчици, които са фокусирани върху използването на софтуер за оптимизиране на производителността и осигуряване на стабилност и надеждност във всички наши системи. Когато разговаряхме с нашия водещ инженер, решихме да определим SRE като професия “Разработчик +”. Плюсът символизира определено допълнително знание, извън писането на код. При мен плюсът е всеобхватно разбиране за това как работи Elasticsearch. За други плюсът може да бъде способността да работят безпроблемно с framework като Ansible или пък дълбоки познания за контейнери. Въобще може да се отнася за всичко свързано с технологиите, което помага в работата на тази позиция.

Друга отличителна характеристика, която смятам, че е важна за един добър SRE, е способността да разбира цялостната работа на системата. Лесно е да разбереш как работят отделните малки парчета, но ключът към професионализма е в това да отстъпиш назад и да разбереш концептуално как всичко се съчетава в едно цяло. Разбирането на високо ниво ни позволява да открием най-слабите точки на системата и да ги подобрим, за да осигурим надеждност.

Като Lead на екипа аз съм отговорна не просто да върша работата си като SRE и да пиша код, но и да определям кои проекти ще бъдат успешни и ще допринесат максимално за компанията и платформата ни.

Какви програмни езици използваш в работата си?

Моят главен и най-предпочитан език е Ruby. Използвала съм го през цялата си професионална кариера. Много хора обвиняват този език за бавен, но напоследък той стана значително по-бърз, а и начинът, по който го използвате, значително влияе на скоростта на изпълнение. Ruby е лесен за изучаване, но като всеки друг програмен език изисква цял един живот, за да бъде овладян напълно.

От колко души е съставен екипът ви и по какви проекти работите?

В момента сме трима, търсим си четвърто попълнение. Екипът работи по няколко основни проекта:

• Ъпгрейд на Elasticsearch до 6.x.
  Последният ни ъпгрейд беше доста труден, затова този път сме осигурили няколко обширни тестинг планове.

• Дефиниране на целите за ниво на обслужване.
  Клиентите ни са щастливи сега, но какво означава това по отношение на метриките ни? Колко бързи трябва да са търсенията, за да запазим нивото на удовлетвореност? Колко бързо трябва да се извършва обработката на данни? Целим да си отговорим на тези и още други въпроси.
• Синхронизиране на виртуални частни облаци (VPC).
  Много от по-големите ни клиенти искат собствен виртуален частен облак за рънване на Kenna, което означава, че разполагаме с много и различни среди. Вероятно се досещате, че работата с всички тях и синхронизацията ни вкарват в истинско предизвикателство. Тъй като през тази година броят на нашите VPC се увеличава, екипът ми се надява да направи работата във всички виртуални частни облаци възможно най-безпроблемна.

Има ли платформа, tool или framework, с който работиш, въпреки че забелязваш проблем?

Това е страхотен въпрос! Разполагам с толкова много примери за tool-ове, които съм използвала прекалено дълго време, до момента в който сформирахме пълен SRE екип и най-после ги заменихме. Всяка от тези промени се отплати неимоверно! Например, преди година имахме проблем с New Relic, защото не съхраняваше данни достатъчно дълго време. Щом SRE екипът се сформира, се заехме със задачата да преминем към Datadog – най-доброто решение, което някога сме взимали!

Друг пример е един tool, който използвахме в продължение на години и ето че най-после успяхме да се отървем от него и да го заменим с Resque. Resque е background processing framework, който използва Redis, за да обработва и траква background jobs. Напоследък той стана много актуален и в момента не е ефективен за нашия случай на употреба, затова наскоро направихме още една промяна – преместихме всички наши background jobs в нов framework, наречен “Sidekiq.”

Sidekiq е много добре поддържан, при него постоянно излизат нови функции и е много по-ефективен от Resque. С поглед напред, следващата система, която най-вероятно ще бъде заменена при нас, е CI решението ни CircleCI. Тъй като се разрастваме,  системата се оскъпи значително и сега сме в търсене на по-практично решение.

В момента изпробваш работата на Ansible, защо реши да направиш тази промяна и какви са ползите от този tool?

Преди 3 години нашият Operations Team направи трансфер от Chef към Ansible за управление на цялата ни инфраструктура. Сега, когато съм SRE, работата ми е много по-тясно свързана с екипа по операциите, затова си поставих за цел да науча повече за Ansible и съответно по какво работят колегите.

Радвам се, че добавям нов tool към технологичния си стек и мога да го използвам, когато разработвам нови SRE фийчъри. Въпреки че съм нова в тази технология, се оказа, че е много лесно да овладееш Ansible на високо ниво. Той дава възможността да пускаш команди на различни сървъри, което е изключително удобно и голямо преимущество, особено при работа и управление на много инфраструктури.

За какво се използва Elasticsearch?

Elasticsearch е в основата на платформата на Kenna и се използва широко за всестранно търсене на активите и уязвимостите на компанията. Самият инструмент е чудесен, когато разполагате с много данни, които трябва да се търсят по сложен начин за кратко време. Той дори е причината да стана SRE. Когато се присъединих към компанията, никой не го беше поел, затова реших да се обогатя с всякакви нови познания. Когато се превърнах в професионалист в работата с Elasticsearch и започнах да работя активно за подобряване на производителността и стабилността, преходът ми от позиция “Software Engineer” към “Site Reliability Engineer” се получи много естествено.

My desk if you are looking for inspiration! Big fan of my Pop head figures and my Educated Guess wine bottle with sunflower 🌻 oh yeah and there’s the Tito’s 😅 pic.twitter.com/BQhJOKcch7

— Molly Struve 🦄 (@molly_struve) May 16, 2019

Коя е най-трудната задача, с която си се сблъсквала в работата си?

О, толкова е трудно да избера само една! Обикновено, това, което ми се е струвало трудно, след няколко месеца ми изглежда толкова лесно…

Мисля, че най-трудната част от работата ми като цяло е дебъгването на проблем в производителността. Например, ако сървърът, който рънва нашата апликация крашне, е моя работа да разбера защо. Това включва преминаване през множество регистрационни файлове и данни в опит да разбера какво точно е правил сървърът по време на срива. Щом разбера какво е правил, трябва да се опитам да позная точно коя задача го е накарала да крашне. За да разбера всичко, което се е случило, е нужно да съм наясно как функционира всяка една част, както и малко прилагане на метода “проба-грешка”. Понякога причината не е лесна за откриване и се налага да се опитвам да позная как може да се оправи. Има и случаи, в които се стига до същинската причина за проблема едва след няколко опита за поправка.

На кой въпрос трябва да може да отговори всеки Lead Site Reliability Engineer?

Една от най-важните стратегии, за която прочетох в SRE книгата на Google, е следната – когато системата се счупи, първото нещо което винаги трябва да направиш е да върнеш системата отново онлайн. Понякога SRE специалистите искат веднага да разберат защо се е случил сривът. Трябва да се борим срещу това желание и да го отложим за момента, след като сме онлайн отново.

Коя фраза поддържа теб и кода ти в най-добра форма? 

”Напред с провала!” – това е фраза, която чух от вицепрезидента на инженерния екип. Той успя да въведе фразата в културата на екипа ни и думите станаха неизменна част от моите вярвания. Всеки път, когато открием счупен код или лош ъпгрейд, ние се опитваме да го поправим и прогресираме. Тази мантра ми напомня, че е окей понякога да се проваляш, но когато това се случи, не трябва да спираш да вървиш напред. Не позволявайте на провала да ви дърпа назад!

Ooof, might be time to call it for the day 😅

But if I am being honest, I won’t until those specs run green pic.twitter.com/LiFoD2URmW

— Molly Struve 🦄 (@molly_struve) June 20, 2019

Интервюто проведе Вяра Стефчева.