Привет!

Продолжаем рубрику «‎СТО на каникулах»‎. Сегодня я, Артем Науменко (Head of Infra), расскажу, как мы рассчитываем затраты на инфраструктуру.

Каждый руководитель инфры или СТО сталкивается с планированием бюджета: сколько серверов докупить, чтобы покрыть потребность бизнеса? Или сколько денег мы потратим на облако в следующем году?

Подобную задачу я решал уже не раз, поэтому поделюсь инсайтами 🙂

🗂 Входные данные

1. План компании по количеству уроков на каждый месяц + прогноз по количеству разработчиков за тот же период.

2. Исторические данные по проведенным урокам + затраты на инфру за прошлые периоды.

🖍 Модель для прогноза

Существуют 3 типа расходов. Каждый коррелирует с планами компании:

1. Stateless сервера (k8s/load balancer, ELK) – количество серверов, пропорциональное количеству планируемых уроков. Я отнес ELK в эту категорию, потому что количество хранимых логов пропорционально количеству уроков при неизменном периоде хранения.

2. Statefull сервера (БД, S3) – количество серверов, пропорциональное суммарному накопленному числу уроков за всю историю компании.

3. Средства разработки – окружения разработки, лицензии на IDE и так далее, пропорциональные количеству разработчиков в компании.

Если есть другие значимые статьи расходов, то стоит подумать, с какими расходами они коррелируют.

💡 Что дальше

Сопоставляем факт по расходам по каждой из категорий серверов / сервисов и факт по метрике компании. Если есть явная линейная зависимость, то все отлично — можно прогнозировать.

Если зависимость нелинейная, то из соответствующей категории серверов вычитаем какую-то часть, которая вероятно коррелирует с чем-то другим. Например, изначально я заложил расходы на хранение видеозаписей уроков пропорционально общему количеству уроков, проведенных в школе. Но, увидев что корреляция не сходится, вспомнил, что мы изменили политику на хранение данных только за последние полгода, после чего все сошлось.

🧮 Считаем

Как только у вас появляется корреляция, можно мыслить в терминах:

📍на каждые 100 уроков в день нам нужно +ХХХ CPU и +УУУ RAM (+3000р. в день на инфру).
📍на каждого нового разработчика или QA нужно +5000р. в месяц на инфру.
📍каждый проведенный урок создает расход на хранение информации о нем в будущем на 1 руб./месяц.

Очевидные проекты экономии в будущем – это очистка старых данных.

После построения модели на нее можно наложить доп. расходы или проекты экономии. Например, наша модель не учитывает новые направления, в которых нет уроков с преподавателем (университет допобразования для взрослых Skypro). Такие расходы можно посчитать отдельно или заложить примерно, если расход незначительный по сравнению с остальными затратами.

P.S. Делитесь в комментах своими подходами. В следующий раз расскажу, как мы автоматизировали работу с инфраструктурой)

Всем привет!
Завершим рабочую неделю еще одним постом про инфру 👋

Инфраструктура часто является узким местом в разработке. До тех пор, пока инфра не создаст базу данных или репозиторий, разработчики не запилят новый сервис и не начнут зарабатывать деньги. В этом контексте важно перестать быть узким горлышком и максимально быстро выполнять запросы от разработчиков. Поделюсь, как мы решаем эту задачу в Skyeng.

1️⃣ С чего начать? Откажитесь от дежурства по очереди и выделите одного ответственного за поддержку, чтобы сотрудник точно был заинтересован в автоматизации работы инфры.

2️⃣ Внедряем CMDB (базу данных управления конфигурациями) для ведения учета за основными сущностями: серверами, базами, сервисами и так далее. Без этого будет невозможен следующий шаг.

3️⃣ Внедряем Service Desk. Это ускорит обработку обращений, которые требуют больше коммуникаций, чем непосредственно нашей работы. Например, выяснить что нужно, а потом объяснить, как пользоваться результатом.

Важно не просто прикрутить Service Desk, а следить за количеством сообщений в каждом обращении и доводить формы запросов до идеального состояния, чтобы обсуждений и уточняющих вопросов вообще не возникало.

Здесь советую использовать данные из CMDB. Например, когда просят доступ в базу данных, то список БД должен подтягиваться из CMDB, чтобы клиент не мог ошибиться в названии БД.

Итак, Service Desk внедрен и обращения максимально формализованы.

4️⃣ Для каждого типа обращения пишем инструкцию, как с ним работать. Мы описываем все, вплоть до того, какой ответ дать автору обращения.

5️⃣ И последнее — строим аналитику, с какими запросами приходят чаще всего. Когда у вас появится аналитика и инструкции по работе с обращениями, автоматизация станет простым и понятным процессом: берете самые частые запросы и автоматизируете согласно инструкции.

Автоматизируйте и наслаждайтесь результатом!

Йо, кукусики 👋
Снова выхожу на связь. Это Серёжа, Head of QA Skyeng. Решил поделиться знакомой QA lead\head болью.

За последний месяц дважды столкнулся с реальным непониманием тимлидов команд нашего требования — пускать QA на все синки.

Особое сопротивление с техревью. Как в классическом меме, аргументация часто сводится к: «Этот QA на ревью нам не нужОн!».

Конкретные пункты звучат так:

🙁 Да он ничего не поймет. Мы-то тут вон какие штуки делаем, а он максимум тесты пописывает.

🧐 Потом ему обязательно (нет) расскажем все тонкости. Смысл ему тратить время? Пусть задачки тестит.

🥺 Он будет нас отвлекать, а у нас по 3-4 задачи на ревью.

Возможно, у большинства это вызовет реакцию: «Ну я-то не такой» и он пойдет обнимет своего QA. Но я знаю, что такая проблема не только у меня.

К сожалению, как и из-за уровня QA в целом, так и из-за стереотипов, для большинства QA — это что-то только про тестирование и где-то отдельно, но не про команду. Каждый подобный кейс с нашими лидами мы прорабатываем: кому-то достаточно аналитики, кому-то примеров «грабель» команд, где QA не звали на общие синки.

Почему на встречах важен QA?

Я бы сходу назвал несколько причин:

📝 Качество — это про ответственность команды, а не только этапа тестирования. Написание красивого кода, который не выполняет все кейсы или не учитывает логику внутри продукта, так же плохо, как и выполнить все условия, но с багами.

📝 Если в силе сотрудника есть сомнения, его не стоит изолировать от команды. Лучше развивать или заменять. Задача крутого лида – создать условия, в которых сотрудники хотят причинить пользу продукту, не ждут очереди и не ограничивают себя на основе субъективных оценок.

📝 Каждый инструмент и каждого сотрудника нужно задействовать так, чтобы он давал максимальную пользу за минимальную стоимость. При производстве стоимость ошибки растёт лавинообразно. Получить фидбек раньше и подумать лишние 20 минут над вопросами QA куда лучше, чем потом 5 часов переделывать.

Это не сверхразум и не рокетсайнс. Это то, что есть в каждом втором учебнике по командообразованию. Но то ли учебники не завезли, то ли у них язык не тот…

А у вас есть такая проблема? Как зарешиваете в своих командах?

Привет!
Скоро закончится рубрика «СТО на каникулах» — ведь и лето подходит к концу. А пока делимся классной штукой про Skyeng Tech.

У нас говорят: «В Skyeng год за три». И не зря — ребята каждые день зарешивают такие челленджи, что просто держись.

Вот несколько историй:

🍀 Дима Кузнецов (Dev Unit Lead) рассказал про эпопею с разработкой системы грейдирования.

🍀 Ира Шанина (Team Lead и Frontend Developer) — о том, как совмещать две роли: руководить командой разработки и писать фронтенд в другом проекте.

🍀 Настя Анисимова (Frontend Developer) поделилась, как сам путь в разработку стал тем еще испытанием и что помогло дорасти до Core-команды платформы.

🍀 Саша Фомиченко (Game Studio Lead) — о дилемме «Что первично: игры или образование?» и зачем вообще Skyeng геймдев-команда.

🍀 Миша Ефанов (Frontend Developer) про кейс, когда за 4 недели команда пересобрала стартовую страницу Skysmart Pro и 12 дополнительных.

🍀 Дима Бормотов (CIS: Head of Growth & Local Products) — о своей сложнопроизносимой должности, большом эксперименте и канале с мемами как главном челлендже (это не шутка).

🔥🤩 Больше видео и текстовых историй ребят собрали на сайте Growthboosters.

Всем привет!

Ищем Dev Team Lead в платформенную команду Skyeng.

Если ты хочешь создавать крутые технические решения для других инженеров и команд, отвечать за стабильность и развитие ключевых сервисов компании, внедрять современные практики backend-разработки и стать настоящим амбассадором в гильдии PHP, го к нам. Будем вместе драйвить развитие — твое и команды 🚀

Что тебе предстоит делать:
👨‍💻 Проводить техревью, реализовывать технические решения в сервисах: авторизация, права и роли, уведомления, сокет-соединения
🚨 Выстраивать SLA, алерты и мониторинги для сервисов
Разрабатывать архитектурные и технические решения
📈 Поддерживать и развивать процессы внутри команды: планирование, scrum, практики тестирования и деплоя
🦸‍♂️ Управлять командой: прокачка, мотивация и найм сотрудников
🚀 Участвовать в кросс-командных проектах и интегрировать решения в экосистему Skyeng

Подробнее по ссылке.

Всем привет! 🙌

Мы давно не выходили на связь. Исправляемся и не откладываем на 2023. Решили больше рассказывать про Skyeng Tech и брать разные темы.

Уже заготовили крутых постов — потихоньку поделимся. Вдруг вы тоже закинете тем и вопросов? Про что интересно узнать? Может конкретные кейсы на нашем опыте.

🔥 А пока — наверстаем упущенное по статьям. Сделали расшифровку доклада с DUMP’22 про ретроспективы.

Наш тимлид из команды Student Cabinet, Лёша Дидух, поработав в нескольких командах с разными культурами и подходами, собрал в статью все, что знает про ретро.

Будет полезно и тимлидам, и юным скрам-мастерам, да и вообще любому, кто хотя бы раз сидел на ретроспективе и думал: «Что я здесь делаю?». Если больше по душе не тексты, а доклады — вот запись 😉

Привет! Я Алина — QA Lead команды платформы.

Платформа — это не продуктовая команда. Мы занимаемся общими компонентами: видеосвязь, авторизация, чаты, пуши, которые используются в разных продуктах компании, а также инструментами и процессами. Своего рода PaaS — Platform as a Service.

Недавно руководители тестирования прошли серию воркшопов по переговорам для прокачки скиллов, проработки трудных кейсов и помощи себе в ежедневных встречах, на которые у лидов уходит добрая часть времени. Поделюсь несколькими ценными выводами. Скипаем small talk и сразу к делу 🔥

На воркшопах мы моделировали кейсы из рабочих будней.

🍀 Встречи, которые начинаются с «Как поживаешь?» иногда интуитивно вызывают чувство неловкости у собеседника. Причины разные: степень знакомства, уместность, желание задавать и отвечать на этот абстрактный вопрос. Нормально сказать: «Привет, спасибо, что пришел/ла. План на встречу у нас такой-то» — и погнали!

На первом этапе озвучиваем повестку и цель, сверяемся с ожиданиями собеседника и не забываем выяснить, что ему важно обсудить.

🍀 По правилам хорошего тона на встречи приходят подготовленными. Но есть нюанс: не стоит настраиваться на конкретные эмоции или пытаться заранее планировать реакцию – свою или собеседника.

Переговоры не стали бы трудными, если бы в начале встречи я не сказала: «Привет, разговор будет непростым». Коллеги давали обратную связь, что после такого старта они были готовы к увольнению здесь и сейчас. Я же таким ошибочным образом пыталась настроить человека на фидбек-сессию по результатам, которые нужно подтянуть 🙂

При переигровке ситуации обсуждение шло естественнее, и я работала с теми эмоциями, которые встретила от собеседника, а не которые прогнозировала.

🍀 Многим мешал заранее подготовленный диалог. Он отвлекал от хода переговоров и не давал в моменте отвечать на вопросы собеседника.

🍀 Методом проб и ошибок мы пришли к тому, что важно задавать вопросы. Нужно быть в контакте с собеседником. Задача — выяснить, почему человек думает именно так: «Что ты имеешь в виду?», «Правильно ли я услышал/а, что…?». Особенно, если точки зрения различаются.

🍀 Говорить о чувствах, а не игнорировать их. Недавно на встрече я поделилась с коллегами, что «испытываю сопротивление делать такую-то задачу» и получила поддержку и понимание вместо спора и осуждения.

🍀 Last but not least — заходить на переговоры в позиции партнера, а не воина. Только отстоять свою точку зрения не является целью. В наших интересах — понять «картину» собеседника, его мотивацию и боли, чтобы с ними работать и находить оптимальные для обеих сторон решения. А список action items обязательно унесите с собой, как артефакт встречи. Кстати, именно с них можно будет начать следующую.

Расскажите о своих инсайтах при ведении переговоров. С какими трудностями сталкиваетесь и как учитесь решать?

Всем привет! 👋
Меня зовут Дмитрий Шкилёв, я тимлид команды Teachers Platform. Мы занимаемся личным кабинетом преподавателя и внутренними ресурсами, которые необходимы для обеспечения работы преподавателей.

Однажды мне надоело заполнять вручную отчет в экселе по результатам производительности команды. И я задумался, можно ли это автоматизировать?

Мы работаем с Jira. Теоретически, можно сделать отдельный Jira-report, но у нас практически нет Java-разработчиков, да и это займет время. Но зато есть Grafana и доступ к реплике БД Jira.

Поэтому выбор пал на связку Grafana + Jira. Нужно было лишь разобраться во внутреннем устройстве БД Jira. Какие-то лайфхаки нашли на просторах сети, где-то использовали отдельные плагины, а где-то — реверс-инжиниринг.

Хочу поделиться результатами и в паре постов на примерах показать, как с помощью Jira и Grafana облегчить жизнь тимлида.

Первый кейс, про который расскажу — грейдирование 🤘

Раз в полгода у нас проходит грейдирование разработчиков. Ребята оценивают сами себя, друг друга и получают оценку от руководителей. Необходимо ответить на вопросы о производительности разработчика и количестве задач, которые вернули после тестирования.

Чтобы определить грейд, необходимо знать точные цифры по каждому разработчику:

1️⃣ % задач, которые были возвращены QA после тестирования на доработку.
2️⃣ % задач, в которых разработчик уложился в оценку.
3️⃣ % задач, которые были сделаны быстрее, чем их оценивали.

Естественно, эти цифры не зависят от респондента, но долгое время каждый отвечал «по личным ощущениям», и они не всегда совпадали с правдой. Так как же считать эти показатели?

▫️С % задач, которые были возвращены QA после тестирования, мне повезло. У нас уже было кастомное поле WasInTesting, которое увеличивалось на 1 каждый раз, когда задача из разработки отправлялась в тестирование. Осталось только посчитать % задач, у которых этот показатель был >1.

▫️Что касается сравнения фактических результатов и планируемых, то количество залогированных часов в Jira есть (поле jiraissue.timespent). Плановые часы мы также сохраняем в отдельном кастомное поле Initial estimate (Original estimate не можем использовать для этого, так как мы его меняем каждый раз перед началом спринта). Остается сравнить количество потраченных часов на задачу и плановых.

У нас есть задачи на исследования, которые мы заранее не оцениваем. Для формирования корректной выборки необходимо исключить их. Это легко можно сделать, если помечать их отдельным лейблом (мы выбрали лейбл research).

▫️Как известно, аппетит приходит во время еды. Поэтому кроме необходимых показателей для ответов на вопросы грейдирования я вывел и ряд других, которые позволяют понять, как человек поработал в этом квартале, увидеть конкретные задачи, на которые ушло много времени. Кроме того, дашборд доступен для всей команды. Каждый видит свои результаты и результаты коллег. Всё прозрачно и непредвзято. Это повышает доверие команды к результатам грейдирования и компании в целом, а также мотивирует ребят на улучшение своих показателей.

Что из этого всего получилось — на скрине. В комментарии подгрузим файлом в более высоком качестве 😉

Привет! Разберем ещё один кейс, с которым помогает связка инструментов Jira + Grafana.

Если:

▫️К вам когда-нибудь приходили с вопросом «А сколько времени ушло на разработку этого сервиса?»

▫️Вам интересно узнать, сколько потрачено времени на разработку своих и не только своих сервисов.

▫️Вы хотите понять, насколько уложились в оценки по разработке новых сервисов.

…то вам будет полезен отдельный дашборд в Grafana c количеством потраченного времени по сервисам.

Я смотрю на три показателя, которые используем в команде:

1) Initial Estimate — изначальная оценка. Ставится один раз после проведения техревью и не меняется. Если по задаче произошёл scope change, то лучше завести отдельную задачу.

2) Original Estimate — у нас это оценка задачи на момент перед стартом спринта (мы перед каждым спринтом проставляем Original Estimate и Remaining Estimate равными цифрами).

3) Logged Time — количество часов, которое залогировали по задаче.

Разница между Initial Estimate и Logged Time показывает, насколько мы ошибаемся в оценке. Original Estimate позволяет контролировать объем задач в спринте.

💡Как это всё работает

Спасибо команде инфры: после деплоя каждой задачи у неё проставляется лейбл deployed-<название сервиса>. По этим лейблам я определяю сервис, в рамках которого шла работа по задаче. Ну а дальше остаётся только просуммировать задачи с группировкой по сервису, в которые были зарезолвлены в обозначенное время.

💡На что обратить внимание

Необходимо следить за лейблами. Обращал внимание на случаи, когда новые задачи заводились путём клонирования и лейблы клонировались от исходной задачи. В итоге у задачи было несколько деплойных лейблов, что приводило к задвоению/затроению оценок.

Анализируя полученные цифры, можно найти для себя ряд сюрпризов. Я, например, обнаружил, что в рамках квартала у нас ушло значительно больше времени на доработку сервиса соседней команды, чем мы рассчитывали.

Если приходится регулярно фиксить баги в каком-то сервисе, то с помощью такого отчёта легко показать бизнесу, сколько времени уходит на поддержку работоспособности сервиса, а это даёт рычаг для обоснования необходимости устранения технического долга.

По количеству сервисов, на которые тратится основной объём времени, тоже можно сделать выводы. Если у вас больше 3 сервисов, на каждый из которых уходит более 5% времени, то это говорит о расфокусировке команды. В этом случае стоит проговорить зоны ответственности и понять, действительно ли вам стоит отвечать за все эти сервисы или есть более подходящая команда. Возможно, пришла пора разделять команду на части.

ребят, привет! это Лёша Катаев

я ушёл из Skyeng делать стартапы, и сегодня запускаю свой продукт на Product Hunt

это Eightify — мгновенные summary для Youtube, GPT-powered

1️⃣ если у тебя есть аккаунт на Product Hunt — поддержи меня там, пожалуйста

2️⃣ если у тебя есть Twitter, репостни мой пост, пожалуйста

спасибо ❤️❤️❤️
P.S. теперь буду писать в твиттер → подписывайтесь

Привет! 👋

Прошлой осенью мы затеяли генеральную уборку. Багатон стал целой эпопеей — на неделю поставили на паузу продуктовые задачи и пошли расчищать багбэклоги (чего мы там только не нашли).

Не все прошло гладко, но история многому нас научила. И, конечно, это был только один из шагов для повышения качества. Но обо всем по порядку.

В общем, про Багатон недавно в деталях поделились на Хабре 🙂

Привет! Грядет февральская TeamLead Conf и коллеги из Яндекса готовят трек — R&D и культура компании 💪

Программа занятная. 7 докладов о том, как в IT-компаниях с разной корпоративной культурой устроены R&D-департаменты, где рождаются, тестируются и запускаются инновационные решения.

Конечно, «инженерную культуру» в сообществе трактуют по-разному. Фокус будет на том, когда разработке для решения продуктовой задачи нужны технологии, которых нет на рынке, или они не доступны.

Послушаем и обсудим:

- Роль бизнеса и инженеров в компаниях с разной корпкультурой.
- Как построены процессы генерации и приоритезации идей и инноваций.
- Как строится взаимодействие между продуктом, разработкой и созданием новых технологий.

И не только. Подробнее о спикерах и тезисах — в программе.
Увидимся на TeamLead Conf! 🔥

Symfony, Laravel или Yii для рабочих проектов? А для личных? И много ли PHP-разработчиков смотрят в сторону Go?

Привет! 👋

Третий год мы с ребятами, которые развивают русскоязычное PHP-сообщество и создают движ для обмена опытом, проводим опрос. Смотрим, как меняется ситуация с фреймворками и версиями PHP в командах, какие статьи и доклады были топ по полезности, какие языки выбирают в качестве дополнительных для изучения и работы. И не только.

🐘 Подвели итоги третьего опроса (за 2022) и собрали результаты в статье и на сайте.

📗 А на phpcommunity.ru можно найти итоги за 2021 и 2020.

#skyeng_habr

Всем привет! 👋

Меня зовут Олег Мифле. В Skyeng работаю над проектом Skypro. В IT я уже больше 10 лет, 7 из которых пишу на PHP. За плечами десятки разных проектов.

Были и классические фуллстек-проекты, и проекты, где фронтенд и бэкенд «живут» отдельно и коммуницируют друг с другом по API. Боль от отсутствия версионирования я испытал на себе.

📖 Поделился в статье на Хабре:

▫️ Зачем версионировать API и нужно ли вообще.
▫️ Какие есть подходы, в чем плюсы и минусы.
▫️ Как избежать типичных проблем версионирования.

Все с примерами и скринами. Приятного чтения! ✌️

#skyeng_habr