Як працюють ІТ-фахівці. Максим Зелінський, компанія «Сбербанк-Технології»

Ми продовжуємо розпитувати фахівців про режим праці та відпочинку, професійні звички, про інструментарій, який вони використовують, і багато іншого.

Буде цікаво з'ясувати, що їх об'єднує, в чому вони суперечать другові. Можливо, їхні відповіді допоможуть виявити якісь загальні закономірності, корисні поради, які допоможуть багатьом з нас.

Сьогодні наш гість - Максим Зелінський з компанії «Сбербанк-Технології». У його компанії багато внутрішніх проектів. Максим пропонує лайфхак, який підходить для тих, хто не вважає себе геніями-багатостанками. Чим
займаєтеся в компанії?

Я відповідаю за розвиток Платформи для завдань Єдиної Фронтальної Системи - системи, яка буде обслуговувати всіх клієнтів Сбербанку у всіх каналах (відділення, інтернет-банки, мобільні додатки, АТМ і так далі). Наша команда займається high-load і high-availability архітектурою, відповідає за вибір технологічних рішень і створює системні та інфраструктурні сервіси.

Одне слово (словосполучення) найкраще описує як ви працюєте:

Хардкорний Research & Development (R&D).

Скільки годин на добу ви приділяєте роботі?

У мене виходить, що я починаю працювати, коли їду в метро. Коли приїжджаю на роботу, починаються мітинги, наради, і десь під вечір я можу продовжити працювати, потім закінчую вдома. В сумі виходить 11-12 годин.

Що ще робите по дорозі на/с роботи?

Коли не розгрібаю робочу пошту в метро, зазвичай читаю книги або мануали за новими технологіями. Завжди треба бути на «вістрі ножа». Зрозуміло, що є люди, які краще мене знають ці технології. І я радий, що вони працюють зі мною, в моїй команді.

Скільки годин ви спите?

Намагаюся спати 8 годин.

Яким to do менеджером користуєтеся особисто ви?

Я пробував Trello. І зараз іноді ним користуюся.

Яким таск-менеджером/issue-tracker'ом/репозиторієм користуєтеся?

Помилка Тих використовує стек Atlassian: JIRA як issue-tracker, Confluence - для wiki і Bitbucket - для Git-репозиторіїв.

Яке робоче середовище використовуєте? Фреймворки, інші сторонні продукти?

Для артефактів ми використовуємо Nexus, де крім Java-артефактів ми так само зберігаємо JavaScript-артефакти у вигляді NPM модулів. Збірка у нас на Jenkins.

Взагалі у нас все досить просто: фронтенд - це JavaScript, бекенд - це Java.

Що стосується технологій, то ми щільно сидимо на React'e як для web, так і для mobile. Зараз ми активно пілотуємо React Native для додатків, які використовують співробітники Банку.

Чи є у вашій команді якісь внутрішні проекти, бібліотеки і для чого вони створювалися?

Наша команда, по суті, тільки і займається створенням бібліотек, призначених для розробників, які вже реалізують бізнес рішення на базі Платформи для різних каналів (інтернет банки, мобільні додатки тощо).

При цьому ми намагаємося бути практиками і створювати бібліотеки тільки для тих кейсів, які, по-перше, реальні (часом доводитися апелювати до YAGNI), по-друге, мають на увазі перекористування між різними командами.

На бекенді ми використовуємо проекти Spring, при цьому ми їх поступово переписуємо під наші завдання. Взагалі проекти, які розвиваються в складі Spring, якщо не брати Spring Framework, дуже різні за якістю і часом не зовсім сумісні: Spring Session, який ми використовували, не до кінця підтримує Servlet специфікацію в частині роботи з HttpSession, що проявлялося в дуже дивній поведінці Spring Web Flow, який ми так само використовували.

При цьому сам Spring Web Flow під наші завдання той же перестав підходити: нам довелося його спочатку сильно модернізувати для підтримки SPA (SWF заточений на server-side відмальовку), і після численних спроб змусити його стабільно працювати (і почасти через непродумані механізми для розширення) ми написали свій аналог, повністю розрахований на роботу з SPA, і який, я сподіваюся, ми незабаром викладемо в open source.

Що вас дратує найбільше, коли ви працюєте?

Всю мою кар'єру я завжди дотримувався принципу You Build it - You run it. Коли команда розробки і команда супроводу - це одна команда (нехай лінійно підпорядковується різним менеджерам), що має одну мету, що відповідає як за time-to-market нового функціоналу, так і за його надійність і продуктивність.

У Сбертехе окрема команда розробки і окрема команда експлуатації. Ми намагаємося взаємодіяти, спілкуємося дуже тісно, але наші KPI не завжди збігаються. Через це виникають конфлікти: ми хочемо щось швидко впровадити, а відділ експлуатації зацікавлений в тому, щоб все було від і до протестовано, мало абсолютно всі механізми по відмовостійкості. Іноді це виправдано, але іноді це просто overhead. В епоху Agile подібна конструкція, на мою думку, повинна зазнати змін. В якості важливого кроку зараз в Сбербанку і СберТехе йде проект по впровадженню практик DevOps, ми всі побачимо перші результати вже в 2017 році.

Мені імпонує система, яка застосовується, наприклад, в Google - коли у кожної команди є свій бюджет по доступності системи, яким вона розпоряджаються. Тобто, якщо протягом декількох релізів система постійно падала, то поки не надолужиться бюджет, експлуатація блокує нові релізи. Але при цьому якщо бюджет є, то команда сама вибирає які рішення по надійності вона застосовує і як, і експлуатація не має права блокувати релізи.

Яку професійну літературу ви б могли порекомендувати?

На мій погляд, найкраща книга з архітектури - Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Там розглянуті всі аспекти: що таке архітектура, хто є її замовником, які аспекти треба висвітлювати в архітектурі і так далі.

Друга книга з архітектури з упором на надійність - High Availability and Disaster Recovery: Concepts, Design, Implementation. Вона трохи застаріла, але там є такий розділ: аналіз цінності рішень щодо відмовостійкості. Ми зазвичай починаємо з якихось простих і щодо дешевих рішень: наприклад, ставимо балансувальники. При цьому ми можемо закінчити жахливим пеклом, який зовсім трохи додає проекту надійності, але розробка цього фрагмента функціональності коштує шалених грошей. Ця книга вчить раціональному підходу: завжди є single point of failure, і що якщо його немає, то ми про нього просто не знаємо.

З легкого читання я рекомендую - Release It. Я вважаю цю книгу корисною абсолютно всім: розробникам, архітекторам, менеджерам.

Що віддаєте перевагу: електронні читалки або паперові книги?

Віддаю перевагу паперовим. Але зазвичай технічна література - це книги по 600 сторінок. Тому доводиться часто використовувати електронні читалки - я для цього використовую iPad першого покоління. Але я все одно намагаюся купувати паперові книги, щоб вони хоча б стояли в моїй домашній бібліотеці.

Яку техніку (комп'ютери, планшети, смартфони) і операційні системи ви віддаєте перевагу на роботі і вдома?

Всі мої мобільні пристрої - це Apple. Принаймні, кілька років тому була актуальна їх головна перевага - висока якість. На жаль, зараз вони стали набагато гірше. Але у мене є старий білий пластиковий MacBook, просто не вбиваний: я там батарейку тільки періодично міняю, і все. Навіть HDD стоїть рідний.

На роботі у нас Windows (крім iOS розробників, природно), але недавно був запущений пілотний проект з переходу на Linux. Багато колег відразу ж у цей проект вписалися.

Ви слухаєте музику, коли працюєте?

Ні, я віддаю перевагу тиші. Музика відволікає мене.

Який лайфхак дозволяє вам бути ефективнішими?

Те, чого я навчився на своєму досвіді - це необхідність делегування. При цьому треба намагатися наймати людей, які розумніші за тебе, щоб можна було зі спокійною душею довірити їм завдання, які навіть тобі не по зубах. Все самому встигнути неможливо.

Без яких додатків і сервісів не можете обійтися ні в роботі, ні в особистому житті?

Очевидно, пошта. WhatsApp - у мене там майже всі друзі сидять. Trello - це мій трекер завдань і активностей.

Що б ви порекомендували людині, яка намагається пройти той же шлях?

Самоосвіта - це найважливіше. У тебе може бути досвіду мало, і ти зараз ще вчишся в інституті, але добре знаєш, наприклад, Core Java, пробував для себе різні технології і робив якісь свої маленькі проекти. У цьому випадку ти вже гідний працювати в компаніях, де ставляться до претендентів як до людей. Просто в деяких компаніях є жорсткий прескринінг: немає досвіду - навіть не дивляться.

А ми завжди дивимося всіх кандидатів і робимо висновки тільки на співбесіді. Я навіть резюме особливо не дивлюся, а просто пролистую, щоб у мене не було упередженого ставлення до людини.

Тому треба постійно займатися самоосвітою. При цьому треба саме добре розбиратися в основах - нічого страшного, що кандидат забув API якогось компонента, але якщо він може розповісти, як він працює всередині (або хоча б припустити, нехай і не зовсім правильно), це вже 100 очок вперед.

Те ж саме стосується і мов програмування - я вважаю, що треба завжди добре орієнтуватися як мінімум у двох мовах, бажано діаметрально протилежних: наприклад Java і Python, або .Net і Erlang. Іноді екосистема однієї мови або технології дуже сильно обмежує мислення.