Серия статей про оптимизации в Go + общие, работающие для любых языков
Пока только первая часть и куча материала в черновиках, очень рассчитываю добраться продолжить
https://medium.com/@armironenko/go-performance-guide-part-1-non-zero-cost-abstractions-6c62f442536b
Пока только первая часть и куча материала в черновиках, очень рассчитываю добраться продолжить
https://medium.com/@armironenko/go-performance-guide-part-1-non-zero-cost-abstractions-6c62f442536b
Medium
Go Performance Guide: Part 1 — Non-Zero Cost Abstractions
Preface about optimizations
Приборная панель тимлида
https://medium.com/@armironenko/must-have-metrics-for-technical-managers-2c99c5b6bc4b
https://medium.com/@armironenko/must-have-metrics-for-technical-managers-2c99c5b6bc4b
Medium
Autopilot for Technical Managers: A Metrics-Driven Approach
As the number of teams, parallel projects, and services you support grows, you eventually reach a point where tracking everything becomes…
Что у нас со скоростью онбординга?
📈 Time to Productivity - как время от старта до 10 Merge-реквеста.
Подход к оценке, используемый в Spotify, очень просто собирается из Gitlab. Может указывать на потенциальные проблемы в:
• Процессе онбординга
• Документации, ее покрытии и актуальности
• Состоянии кода, сложности архитектуры и инфраструктуры, когнитивной нагрузке из-за кол-ва сервисов в ответственности у команды (это как правило видно и по Cycle Time)
Кроме того, метрика может быть полезна:
• В проектном управлении - для прогнозирования velocity команды и оценки сроков при добавлении новых разработчиков
• Для более точной оценки стоимости перенайма
📈 Time to Productivity - как время от старта до 10 Merge-реквеста.
Подход к оценке, используемый в Spotify, очень просто собирается из Gitlab. Может указывать на потенциальные проблемы в:
• Процессе онбординга
• Документации, ее покрытии и актуальности
• Состоянии кода, сложности архитектуры и инфраструктуры, когнитивной нагрузке из-за кол-ва сервисов в ответственности у команды (это как правило видно и по Cycle Time)
Кроме того, метрика может быть полезна:
• В проектном управлении - для прогнозирования velocity команды и оценки сроков при добавлении новых разработчиков
• Для более точной оценки стоимости перенайма
CockroachDB … Press F
• В 2019 году Cockroach Labs поменяла лицензию с Apache на BSL, ограничивая коммерческое использование в SaaS без покупки лицензии.
• В августе 2024 компания внесла новые изменения в лицензионную политику, а также отказалась от Core (бесплатной) версии. Теперь только Enterprise, и c покупкой коммерческой лицензии, если доход превышает 10 млн $. Купить легально из РФ нельзя, на этом, собственно, все.
В Авито во времена масштабирования на 3 дата-центра был очень успешный эксперимент с внедрением, а впоследствии CockroachDB полноценно заехал и во внутренний DBaaS.
Если по профилю нагрузки сервис терпим к latency, особенно на запись, то дальше только сплошные плюсы:
• HA и горизонтальный скейлинг из коробки,
• Distributed SQL и (только) Serializable-транзакции,
• Обновление без простоя.
Конечно, есть и другие NewSQL СУБД, например, YDB, но, кстати, в этом году после ряда инцидентов в Яндекс.Маркете нам ее забанили для использования в бизнес-критических сервисах.
🔭 Интересно будет в свободное время потрогать руками Yugabyte и TiDB (как и в CockroachDB, за основу взята архитектура Google Spanner)
• В 2019 году Cockroach Labs поменяла лицензию с Apache на BSL, ограничивая коммерческое использование в SaaS без покупки лицензии.
• В августе 2024 компания внесла новые изменения в лицензионную политику, а также отказалась от Core (бесплатной) версии. Теперь только Enterprise, и c покупкой коммерческой лицензии, если доход превышает 10 млн $. Купить легально из РФ нельзя, на этом, собственно, все.
В Авито во времена масштабирования на 3 дата-центра был очень успешный эксперимент с внедрением, а впоследствии CockroachDB полноценно заехал и во внутренний DBaaS.
Если по профилю нагрузки сервис терпим к latency, особенно на запись, то дальше только сплошные плюсы:
• HA и горизонтальный скейлинг из коробки,
• Distributed SQL и (только) Serializable-транзакции,
• Обновление без простоя.
Конечно, есть и другие NewSQL СУБД, например, YDB, но, кстати, в этом году после ряда инцидентов в Яндекс.Маркете нам ее забанили для использования в бизнес-критических сервисах.
🔭 Интересно будет в свободное время потрогать руками Yugabyte и TiDB (как и в CockroachDB, за основу взята архитектура Google Spanner)
Цикл PDCA (Plan-Do-Check-Act)
Простой, но эффективный инструмент для системного улучшения процессов, решения задач и достижения целей. Концептуально это итеративный цикл из четырех этапов:
🎯 Plan (Планирование)
⚡ Do (Выполнение)
📊 Check (Проверка)
🚀 Act (Действие)
Чтобы PDCA работал максимально эффективно, важно не просто механически проходить этапы, но и задавать ключевые вопросы:
1. Plan (Планирование)
• Что делаем, какой результат хотим получить? → Задача или цель в виде понятного образа результата, например по SMART.
• Кто и что для этого делает? → Распределяем роли и зоны ответственности.
• Когда и как оцениваем результат? → Определяем метрики и сроки проверки.
2. Do (Выполнение)
• Реализация плана.
3. Check (Проверка)
• Сравниваем фактический результат с ожидаемым, например на основе метрик.
• Анализируем: Что сработало? Что пошло не так? Почему?
4. Act (Действие)
• Если результат хороший → масштабируем.
• Если плохой → корректируем подход и запускаем новый цикл.
В качестве примера, PDCA лежит в основе любой Agile методологии, а так же может использоваться для постановки и контроля индивидуальных планов развития.
Простой, но эффективный инструмент для системного улучшения процессов, решения задач и достижения целей. Концептуально это итеративный цикл из четырех этапов:
🎯 Plan (Планирование)
⚡ Do (Выполнение)
📊 Check (Проверка)
🚀 Act (Действие)
Чтобы PDCA работал максимально эффективно, важно не просто механически проходить этапы, но и задавать ключевые вопросы:
1. Plan (Планирование)
• Что делаем, какой результат хотим получить? → Задача или цель в виде понятного образа результата, например по SMART.
• Кто и что для этого делает? → Распределяем роли и зоны ответственности.
• Когда и как оцениваем результат? → Определяем метрики и сроки проверки.
2. Do (Выполнение)
• Реализация плана.
3. Check (Проверка)
• Сравниваем фактический результат с ожидаемым, например на основе метрик.
• Анализируем: Что сработало? Что пошло не так? Почему?
4. Act (Действие)
• Если результат хороший → масштабируем.
• Если плохой → корректируем подход и запускаем новый цикл.
В качестве примера, PDCA лежит в основе любой Agile методологии, а так же может использоваться для постановки и контроля индивидуальных планов развития.
Лайфхак: как можно использовать Telegram для ведения заметок, если вы еще не нашли для себя подходящий инструмент.
Создаем группу на одного себя (например, «Мои заметки») и включаем режим тредов (обсуждений)
📝 Что получаем в итоге:
1. Разбивку через треды по категориям (1 уровень)
2. Синхронизацию между любым количеством устройств
3. Голосовые сообщения (и транскрипция) — идеально, чтобы, например, надиктовать мысль в дороге
4. Быстрый поиск
Создаем группу на одного себя (например, «Мои заметки») и включаем режим тредов (обсуждений)
📝 Что получаем в итоге:
1. Разбивку через треды по категориям (1 уровень)
2. Синхронизацию между любым количеством устройств
3. Голосовые сообщения (и транскрипция) — идеально, чтобы, например, надиктовать мысль в дороге
4. Быстрый поиск
В последнее время всё чаще натыкаюсь на обучающие программы и повышенный интерес к технике «Жестких переговоров», которую начинают воспринимать как универсальную - быструю, прямолинейную и якобы гарантированно результативную.
Но в корпоративной среде, особенно когда речь идет о взаимодействии между командами, такой подход дает весьма спорный результат.
Недавний кейс - нужно было договориться со смежной командой об оперативных доработках. Как это обычно бывает, их ресурсы уже были запланированы под собственные, более приоритетные задачи. При этом у нас был серьезный рычаг, с помощью которого мы могли бы быстро добиться нужного нам решения.
Но мы сознательно им не воспользовались.
Да, давление позволило бы решить проблему здесь и сейчас, но ударило бы по отношениям и снизило бы доверие. В долгую это означало бы, что в следующей аналогичной ситуации, особенно если подобного рычага уже не окажется, договориться было бы куда сложнее или вообще невозможно.
Мы выбрали другой путь: вложились в диалог, разобрали ситуацию с обеих сторон и вместе нашли вариант, как выделить ресурсы в приемлемые для нас сроки. Это заняло больше времени, но сохранило рабочие отношения, выровняло контекст и создало основу для более эффективного сотрудничества в будущем. В подобных ситуациях Гарвардский метод показывает себя куда более устойчивым и продуктивным.
Но в корпоративной среде, особенно когда речь идет о взаимодействии между командами, такой подход дает весьма спорный результат.
Недавний кейс - нужно было договориться со смежной командой об оперативных доработках. Как это обычно бывает, их ресурсы уже были запланированы под собственные, более приоритетные задачи. При этом у нас был серьезный рычаг, с помощью которого мы могли бы быстро добиться нужного нам решения.
Но мы сознательно им не воспользовались.
Да, давление позволило бы решить проблему здесь и сейчас, но ударило бы по отношениям и снизило бы доверие. В долгую это означало бы, что в следующей аналогичной ситуации, особенно если подобного рычага уже не окажется, договориться было бы куда сложнее или вообще невозможно.
Мы выбрали другой путь: вложились в диалог, разобрали ситуацию с обеих сторон и вместе нашли вариант, как выделить ресурсы в приемлемые для нас сроки. Это заняло больше времени, но сохранило рабочие отношения, выровняло контекст и создало основу для более эффективного сотрудничества в будущем. В подобных ситуациях Гарвардский метод показывает себя куда более устойчивым и продуктивным.
Настоящий качественный отдых - мастхев, именно он дает возможность быть эффективным, принимать взвешенные решения и сохранять фокус на длинной дистанции.
А приложение Welltory помогает это контролировать, всем советую
А приложение Welltory помогает это контролировать, всем советую
Простым языком о времени в распределенных системах.
Статья долго лежала в драфте, и вот - наконец-то готово.
Делюсь, вдруг кому-то будет полезно 🙌
https://medium.com/@armironenko/distributed-systems-logical-time-explained-5f97949f180f
Статья долго лежала в драфте, и вот - наконец-то готово.
Делюсь, вдруг кому-то будет полезно 🙌
https://medium.com/@armironenko/distributed-systems-logical-time-explained-5f97949f180f
Medium
Distributed systems: Logical Time Explained
In a distributed system, there is no shared, global clock. Every node maintains its own physical time, which may run fast or slow, jump…