Мамкін Архітектор

Зараз несеться DOU award. Ось можете підтримати автора україномовного youtube каналу про AWS https://t.me/devops_in_ukrainian/21

Продовжуємо розказувати про k8s (це так хіпстери девопси пишуть kubernetes, бо між k та s рівно вісім літер — можете перерахувати, якщо не вірите). Цього разу дізнаємось, шо там зі сховищем.

Бо з минулих постів зрозуміло, як створювати поди, і як отримати до них доступ. Але де поди зберігають свої дані? Наче дурне питання з відповіддю "на диску, де ж ще", проте якщо почати задумуватись, що буде з данними, якщо нода відвалиться, чи кубернетес вирішить прибити под і перезапустити його на іншій ноді (а він це може), то стає зрозумілим, що "просто на диску" це не відповідь.

А правильна відповідь "Volumes". У Kubernetes Volume — це абстракція для зберігання даних, доступних контейнерам у поді. Основна ідея в тому, що на відміну від звичайного файлового простору контейнера, який зникає при його перезапуску, томи можуть зберігати дані довше.

Приклади типів томів:
1. emptyDir – створюється при запуску пода, видаляється після його завершення.
2. hostPath – використовує файлову систему ноди (ризикований варіант).
3. configMap, secret – використовуються для зберігання конфігурацій і секретів. Тут створюються окремі сутності в k8s, для яких можна задати їх значення окремо.
4. persistentVolumeClaim (PVC) – запит на збережене сховище (PersistentVolume).

Все наче зрозуміло, крім останньої штуки. Це комбінація двох типів ресурсів:

PersistentVolume (PV) – це ресурс сховища, який існує незалежно від життєвого циклу подів. Він може бути створений адміністратором вручну або автоматично через StorageClass.

PersistentVolumeClaim (PVC) – це запит на певний обсяг сховища. Якщо у кластері є відповідний PV, він зв’язується з PVC, і под може його використовувати.

Працює все приблизно так:
- Адміністратор створює PersistentVolume (PV) – визначає фізичне сховище.
- Додаток створює PersistentVolumeClaim (PVC) – запитує місце в сховищі.
- Kubernetes зв’язує PVC з відповідним PV.
- Под використовує PV як Volume для зберігання даних.

Проте адміністраторі зазвичай ліниві, і вручну нічого не хочуть створювати, і тому вони придумати StorageClass, який дозволяє автоматично створювати PV при запиті PVC. Це особливо корисно в хмарних середовищах (AWS EBS, GCE Persistent Disk). Проте і є рішення, аби робити це on premises (я от використовую longhorn)

І в кінцевому вигляді воно виглядає так
- додаємо StorageClass до кластеру (хай це буде AWS EBS)
- в описі поди описуємо PVC певного розміру і потрібного класу
- під час створення поди кубернетес дивиться, чи було для цього PVC створено PV, якщо так, то підключає його до поди. А якщо ні — то створює і підключає.
- потім, коли пода переїзджає на інше місце, то PV переїздить разом з нею

Таким чином, отримуємо виртуальну директорію, яка мандрує разом з подом. Все це звучить складніше, ніж є насправді, і на практиці доволі зручно.

#реклама Якщо вам недостатньо постів про кубернетес, то ось є цілий курс від партнерів. Від себе додам, що лектор — з нашого комьюніті.

🦾 Docker, Kubernetes і Terraform

Автоматизувати розгортання застосунків, забезпечувати відмовостійкість систем, стежити за безпекою продуктів, моніторити, керувати й швидко виправляти помилки задачі — роль DevOps Engineer.

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

Інтенсивна програма містить 38 занять — про віртуальні машини, хмарні обчислення, контейнеризацію, CI/CD, моніторинг, керування інфраструктурою як код та багато іншого.

За 4 місяці ви опануєте ключові інструменти, які використовують девопси у своїй роботі, та розробите фінальний проєкт — застосунок на базі мікросервісної архітектури, який охоплює всі ключові аспекти DevOps.

Лектор — Владислав Папідоха, DevOps Engineer у TENTENS Tech by SKELAR.

Навчання стартує 11 березня.

Детальніше про курс 🔗

Загалом діаграми від byte byte go треба сприймати with a grain of salt, але для загальної ерудиції деякі доволі непогані.

Продовжуємо про кубернетес. З подами і деплойментами більш менш розібрались, шо далі? А далі треба наші поди якось зробити доступними для взаємодії, як зсередини кластера, так і (можливо) ззовні. Сам по собі под здається має айпішнік (я не дуже в цьому шарю, і насправді цього не треба знати, аби бути експертом з кубернетеса), але напряму я не чув, аби воно використовувалось. Натомість усім рулять services.

В кубернетесі сервіс — це абстракція, яка надає стабільний мережевий доступ до групи подів (або інших ресурсів). Якщо коротко -- то це IP адреса і DNS імʼя. Нащо треба окрема абстракція? Просто поди — це не дуже надійні сутності. Вони можуть падати і підніматись на інших нодах, і кожного разу в них будуть різні IP адреси. А сервіс це умовний лоад балансер, що має стабільний IP і надає доступ до подів, де б вони не були.

Сервіси бувають різних типів:

ClusterIP — дефолтний тип, просто робить IP всередині кластера, без зовнішнього доступу.

NodePort — відкриває вказаний порт на усіх нодах кластеру. Таким чином усі поди доступні ззовні через усі ноди за цим портом. Навіть якщо нода не містить цих подів, через поди доступні.

LoadBalancer — робить поди доступними з зовнішнього інтернету. Зазвичай воно працює в cloud сетапах, тут задіюється load balancer клауду, виділяється зовнішня айпішка, і по ній сервіс (а відповідно і поди) стає доступним в світ. Але за певних умов воно може використовуватись і в on premises сетапі.

ExternalName — трошки виділяється з цієї компашки, бо тут надається доступ до чогось зовнішнього через внутрішній IP / DNS. Наприклад, можна зробити, аби зовнішні сервери kafka були доступними по імені kafka.

Що ще варто додати до сервісів, так це те, що вони надають доступ не лише до подів. Насправді, в описі сервісу є такий собі selector, який визначає критерії того, до чого треба доступ. І в ці критерії можуть попадати і інші сервіси. Таким чином, якщо в нас є ClusterIP сервіс, можна зробити LoadBalancer, в селекторі якого описати цей сервіс і він стане доступним назовні. (В коментарях вказали, що це не зовсім так)

Ну і мабуть варто розказати, шо ж це за селектори. Справа в тому, що в описі ресурсів можна вказати набір метаданих, які називаються labels. Це набір ключ / значення, які можуть бути будь-якими. Ну а селектор перераховує лейбли, за якими будуть обиратись ресурси, до яких застосовується певна конструкція (в нашому випадку сервіс). Наприклад, якщо в описі деплойменту ми вкажемо app: yoba, і у селектора сервіса теж app: yoba, то цей сервіс надаватиме доступ до всіх под, які створюються тим деплойментом.

Якщо ви чекали постів про кубернетес для недевопсів (розробників чи QA чи може навіть менеджерів то ось перший з них.

Кубернетес — це такий собі розподілений docker compose, але на стероїдах. Якщо в двох словах — воно дозволяє вам запускати контейнери на кластерах з одного чи більше серверів (вони називаються "ноди"). І забирає на себе весь клопіт щодо визначення де запустити, шо робити, якщо якась нода відвалиться, як зробити, аби під час оновлення не було даунтайму, і вирішить ваші матеріальні проблеми, якщо ви вирішите стати девопсом.

Давайте почнемо з простого а шо може бути простіше за поди (pods)? Pod — це мінімальна одиниця деплоймента в кубернетесі. Хтось може спитати "а чому не контейнер", а я відповім, що pod може мати декілька контейнерів. Там може бути, наприклад, init container, який запускається першим, і по результатам роботи якого інші можуть і не запуститись (такий собі скаут). Або ж просто декілька контейнерів, що працюють одночасно. Вони всі знаходяться в одному мережевому просторі, і можуть мати спільні файлові ресурси через volumes.

Але зазвичай в pod запускається один контейнер. Можна запустити декілька інстансів pod, вони називаються репліками. Для того, аби зручно було робити репліки, у кубернетеса є спеціальний тип ресурсу, replica set. Він описує саму поду (хз який там має бути рід), і скільки штук їх треба запустити. Насправді replica set — це контролер, і вони бувають різними, проте про це напишемо у майбутніх випусках.

Replica set це зручно, їх можна створювати напряму, але є ще прикольніше варіант, який називається deployment. Це — максимально потужна штука, яка описує як сам replica set, так і різні правила, як треба його розгортати. Наприклад, можна вказати, що під час оновлення нам треба завжди тримати мінімум 2 робочих поди, і таким чином забезпечити доступність нашого сервісу.

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

Ось вам трохи безкоштовних порад про те, як бути добрим підлеглим.

Не кажіть своєму менеджеру "я зашиваюсь, в мене не вистачає часу". Може банально прозвучить, але вас скоріш за все наймали,аби ви все встигали :)
Ви маєте оцінювати свій час і планувати задачі відповідно.

Добре, але ж не можна встигнути все? Звісно, не можна. Просто про такі ризики треба говорити заздалегідь. І не з позиції, що ВИ не встигаєте, а "є ризик того, що МИ не зробимо це до того часу, бо там є ТЕ і ЦЕ. Допоможи визначити пріоритети, я думаю, що ми можемо ЦЕ посунути".

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

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

За мотивами попереднього посту (насправді, коментарів) пишу ось цей. А буде він про liveness checks.

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

Так от, схема наступна: пода виставляє певні ендпоінти, кубернетес їх періодично перевіряє, і якщо там глухо, або помилки, то рестартує поду. Рішення класне і спрямоване на підтримання роботоздатності сервісу, і лікує ті проблеми, шо лікуються рестартом.

Проте на практиці це використовують не завжди правильно. Чомусь вважається гарною ідеєю виставити в якості метрик здоровʼя сервісу доступність його залежностей. Наприклад, бази даних. І якщо база недоступна, то сервіс вважається мертвим і, відповідно, перезапускається.

І ось які я бачу в цьому проблеми:

Не всі ендпоінти вимагають бази для своєї роботи. Десь може кеш, десь ще щось може відпрацювати. Або уявіть, що користувач оплачує замовлення, система ось-ось пушне повідомлення про це в умовну кафку, а тут бабах – рестарт сервера.

На рестарт сервісу треба якийсь час. Дуже іронічно, що в коментах написали, що такий підхід є стандартним для Java Spring Boot, бо саме java сервіси можуть по декілька хвилин витрачати на старт.

Ну і саме головне — а шо ж цей рестарт пофіксить? База стане доступною? Мабуть ні. А так сучасні фреймворки і драйвери вміють обробляти помилки залежностей, робити повторні запити, тримають кеш зʼєднань і роблять усе інше, аби зуміти нормально все опрацювати і відновитись. Без рестарту сервісу.

Тому авторитетно заявляю, що такий механізм liveness checks — неефективна фігня. Напишіть, в чому я неправий (або поставте зірочок)

В твітері натрапив на цікаве питання:

Що краще:
1. Якщо бекенд не може приєднатися до БД він падає і рестартує, по АРІ 50* помилки (від Nginx, наприклад);
2. Якщо бекенд не може приєднатися до БД він запускається і працює, пробує конектитись до бази, але віддає по АРІ для яких треба БД сам якусь помилку.

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

Але насправді перший підхід буде складніше зробити. Бо в сучасному світі доволі складно знайти веб фреймворк (ми ж про них говоримо? бо там 50* помилки згадуються), який би сам падав від неочікуваних помилок. Зазвичай там все вбудовано, вони хендляться, генеруються 500 відповіді і все просто працює. А якщо хочеш, аби воно падало вдрабадан, то треба підключатись до обробки помилок, там сіяти якусь kernel panic (це я фігурально написав, не треба виправляти мене в коментах... хоча виправляйте, хто я такий, шоб вам заборонити). Купа додаткової роботи.

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

Тому, починаючи з кінця 90х (чи коли там веб сервери перестали створювати новий процес на кожен запит), кращим варіантом буде 2.

Задавайте тепер ваші відповіді в коментах.

Прочитав новину, що якщо в посиланні на будь-яке github repo замінити .com на .gg, то відкриється чат з AI, де можна отримати відповіді на усі питання по цьому репо.

Майже схоже на правду, але поки що сходу отримуємо rate limit (мабуть reddit ефект, поспостерігаємо, може скоро попустить)

Я думаю ви в курсі, шо таке deepseek. Китайський опенсорсний конкурент chatGPT, який наче працює краще, а коштує в 15 разів дешевше. За дуже короткий час зайняв топ 1 в апсторах, і зараз усі лише про нього і говорять.

На моїй памʼяті це вже третій приклад, коли технологічний продукт з Китаю вривається з ноги на західний ринок і розкидає усіх конкурентів, що панують тут роками. Tiktok, temu, і зараз ось deepseek.

Можна зрозуміти, як китайські товари заполонили світ. Дешеве виробництво, усі все почали робити в Китаї, при цьому хитрі китайці "надихались" і почали робити свої версії, які дешевші, поступово підвищуюючи якість.

Але аплікухи — тут я не можу зрозуміти, як техно гіганти це допускають. Чому умовний youtube не задавив tiktok, amazon — temu, ну і openai теж жує соплі. Адже всі говорять, що корпорації правлять світом, і це мабуть так і є.

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

Що думаєте?

З подивом побачив в одному з проектів інструкцію "додайте в /etc/hosts рядок 127.0.0.1 app.your-awesome-domain.local "

Зрозуміло, нащо це робиться – потрібно щось затестити з якимось доменом. Це може бути роутинг по Host заголовку (до речі, англійською Header читається, як хЕде, а не хІдер), або ще шось таке.

Проте міняти hosts файл це моветон. Там треба sudo права, і взагалі робити зміни на глобальному рівні під якийсь конкретний проект — не найкраща ідея.

Натомість краще використовувати сервіси типу nip.io або traefik.me. Як вони працюють — прочитайте на їх сторінках.

В результаті отримуємо гарненькі домени, що працюють локально.

Що скажете, правильно все намальовано?

🔹 Cookie vs HTTP Headers: в чому різниця?

Cookie і HTTP Headers — два важливі механізми для передачі даних між клієнтом і сервером. Давайте розберемось у їх відмінностях:

🍪 Cookie
• Використовуються для зберігання даних на стороні клієнта (наприклад, сесії, налаштувань, токенів).
• Браузер автоматично додає кукі до кожного HTTP-запиту до домену, якому вони належать.
• Однак кукі не додаються автоматично до XHR (XMLHttpRequest) або fetch-запитів, якщо не вказати опцію credentials: 'include'.
• Cookie можна налаштувати як HttpOnly, щоб заблокувати доступ до них через JavaScript. Це підвищує безпеку, особливо для зберігання токенів доступу.

📩 HTTP Headers
• Використовуються для передачі мета-інформації між клієнтом і сервером (наприклад, токенів аутентифікації через Authorization, інформації про типи даних, які підтримуються, і т.д.).
• Контролюються JavaScript (наприклад, через fetch або axios), що дає більше гнучкості у виборі, які дані надсилати та коли.

🔒 Чому HttpOnly важливий?
Кукі з прапором HttpOnly недоступні JavaScript. Це захищає їх від атак типу XSS (коли зловмисники можуть виконувати шкідливий скрипт на сторінці й викрасти ваші дані).

📌 Автоматичність Cookie проти гнучкості Headers
• Cookie автоматично додаються до звичайних HTTP-запитів (GET, POST тощо). Проте для XHR або fetch-запитів треба додатково налаштовувати параметри.
• Headers більш контрольовані: ви самі вирішуєте, які токени чи дані передавати, і не залежите від автоматизації браузера.

💡 Коли що використовувати?
• Cookie підходять для зберігання сесій або CSRF-токенів.
• HTTP Headers зручні для роботи з API, особливо з Bearer токенами для аутентифікації.

Вибір залежить від ваших задач та рівня безпеки, який вам потрібен. 🚀

Референс архітектура мого todo list на два користувача.

“Geohash vs QuadTree: хто кращий у пошуках зниклих сосисок?”

Уяви, що ти керуєш доставкою хот-догів (чи сосисок, як тобі ближче) і хочеш знати, де зараз твій кур’єр. У нього GPS, у тебе карта, але ти не можеш постійно шукати його координати вручну. Тут на допомогу приходять геопросторові структури даних – geohash і QuadTree. Розбираймося, хто з них твій майбутній бро.

Geohash: координати на дієті

Geohash – це коли GPS координати стискають у симпатичний рядок типу u4pruydqqvj. І ось як це працює:
1. Розбиваємо Землю на квадратики. Спочатку глобально – на два (північ/південь), потім ще дрібніше, поки не отримаємо рівень точності, що нас влаштовує.
2. Кодуємо квадратики. Кожен квадрат має своє унікальне ім’я, яке формується з бітів, а потім перетворюється на рядок.

Чому це зручно? Бо сусідні квадрати мають схожі geohash-коди. Наприклад, u4pruyd і u4pruyf – це сусіди. Пошук близьких точок стає простішим!

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

QuadTree: дерево, яке росте до Землі

QuadTree – це деревоподібна структура, яка ділить простір на квадратики, але більш ієрархічно:
1. Розбивка. Кожен квадрат ділиться на 4 менші квадрати, і так далі, поки ми не досягнемо потрібної точності.
2. Зберігання. Дані про об’єкти зберігаються в “листі” дерева (найменший квадрат).

QuadTree зручний тим, що:
• Він гнучкий. Можна зберігати не тільки точки, але й багатокутники.
• Квадрати завжди квадратні (вибач за тавтологію).

Кому що підійде?
• Geohash: коли тобі треба ефективно кодувати координати та швидко знайти сусідні точки. Наприклад, пошук кур’єрів у радіусі 1 км.
• QuadTree: якщо у тебе складніші запити – наприклад, визначити, які будинки накриває зона доставки чи знайти всіх клієнтів у конкретному районі.

Фіналочка

Geohash – це ніби ти загортаєш Землю у зручний рядок. А QuadTree – це як Lego, де ти будуєш Землю з квадратиків. Кожен інструмент крутий у своїй задачі.

Так що вибирай, що тобі ближче: компактність чи контроль. Ну, і не забудь, що в будь-якому випадку кур’єр все одно їде через затор.

“Консистентний хешинг: твій новий бро в світі балансування”

Уяви: ти власник бургерної, у тебе три каси, і ти вирішив, що клієнти розподіляються за останньою цифрою їхнього номера телефону. Все йде норм, але тут приходить четверта каса, і ти думаєш: “Окей, тепер ділитимемо клієнтів на чотири групи”.

Капець. Половина клієнтів не знає, до якої каси їм тепер іти, бо стара логіка полетіла в трубу. Зате черги ростуть, касири в стресі, а ти мрієш про відпустку на Балі.

А тепер серйозно: така ж проблема виникає в реальних системах, коли ти додаєш або видаляєш сервери в кластері. Стандартне хешування викликає хаос у розподілі ключів між серверами. І ось тут на арену виходить consistent hashing – хешування, яке не ламає все довкола.

Як це працює?
1. Кільце хешів. Уяви собі коло, де кожен сервер – це точка на ньому. Дані теж кладемо на це коло.
2. Розподіл. Кожен ключ (наприклад, “user123”) хешується і потрапляє на певну точку на кільці. Дані зберігаються на найближчий за годинниковою стрілкою сервер.
3. Магія масштабування. Якщо додаєш новий сервер, він бере собі лише частину ключів. Видаляєш сервер – його ключі розподіляються між сусідами.

Чому це круто?
• Мінімум перескладання. При додаванні чи видаленні серверів змінюється тільки невелика частина даних.
• Гнучкість. Легко масштабувати кластер без великих втрат продуктивності.
• Юзер-френдлі для DevOps. Менше головного болю при оновленнях.

Застосування
• Балансування навантаження (наприклад, в кешах типу Redis чи Memcached).
• Шардінг баз даних.
• Системи зберігання файлів, наприклад, Amazon Dynamo чи Cassandra.

Тому якщо тобі здається, що твої сервери – це каси бургерної, і всі клієнти метушаться, задумайся про consistent hashing. Бо без нього – як без кетчупу в чізбургері: працювати можна, але відчуття не ті.

“Leaky Bucket vs Token Bucket: обери своє відро у боротьбі з DDoS”

Уяви, що ти охоронець на вході в нічний клуб. Люди ломляться натовпом, але ти не можеш впустити всіх одразу — інакше всередині буде хаос. Треба обмежити, скільки людей заходить. У світі мережевого трафіку це вирішується за допомогою Leaky Bucket і Token Bucket. Розбираймося, як працюють ці відра, щоб і порядок був, і ніхто не образився.

Leaky Bucket: тримай себе в руках

Leaky Bucket (протікаюче відро) працює дуже просто:
1. Уяви, що трафік — це вода, яку ти зливаєш у відро.
2. Вода витікає з відра стабільним потоком (наприклад, 10 пакетів/сек).
3. Якщо води (трафіку) надто багато і відро переповниться, зайве просто проллється — воно ігнорується.

Що це значить?
• Ти жорстко контролюєш швидкість виходу трафіку.
• Якщо хтось намагається тебе перевантажити, зайве просто відсікається.

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

Token Bucket: бери жетон — заходь

Token Bucket працює трохи хитріше:
1. Уяви, що в тебе є відро, але тепер у ньому не вода, а жетони.
2. Жетони додаються в відро з певною швидкістю (наприклад, 10 жетонів/сек).
3. Щоб пройти (або відправити пакет), клієнт бере жетон. Немає жетонів — немає доступу.

Фішка: жетони можуть накопичуватися! Тобто якщо трафіку певний час не було, відро наповнюється, і ти можеш обробити великий сплеск.

Переваги:
• Гнучкість: система може “пропустити” сплеск трафіку, якщо до цього було затишшя.
• Менше втрат у порівнянні з Leaky Bucket.

Кому що підійде?
• Leaky Bucket: коли тобі треба жорстко лімітувати швидкість трафіку, наприклад, у випадках, коли перевантаження просто неприйнятне.
• Token Bucket: якщо ти хочеш більше гнучкості, дозволяючи обробляти сплески трафіку. Наприклад, для API-лімітів, де важливо зберегти баланс між доступністю і контролем.

Фіналочка

Leaky Bucket — це строгий швейцар, який каже: “Один за одним і без штовханини”.
Token Bucket — це дружній касир, який каже: “Якщо у тебе є жетон — проходь, хоч зараз, хоч через годину”.

Обидва підходи круті, але все залежить від твоїх завдань. А поки ти вибираєш, пам’ятай: DDoS-атаки не сплять.

💡 Історія графічного інтерфейсу: як Xerox створив революцію, але не скористався шансом

Колись я був вражений, коли побачив перший графічний інтерфейс з іконками, мишею, “робочим столом” та папками. Але ще більше здивування викликала історія його створення.

Уявіть, що на початку 70-х компанія Xerox — піонер у виробництві копіювальних машин — почала розуміти, що комп’ютери загрожують її бізнесу. Чому? Тому що з появою цифрових технологій потреба в паперових документах почала зменшуватись.

Щоб адаптуватися, Xerox створила дослідницький центр PARC (Palo Alto Research Center). Метою було розробити нове середовище, яке б замінювало паперовий документообіг, але при цьому стимулювало попит на продукцію Xerox. Так і з’явився прототип сучасного графічного інтерфейсу: робочий стіл, папки, іконки, вікна та мишка.

Проте керівництво компанії не змогло оцінити потенціал цієї ідеї. Вони не вкладалися в просування, а маркетинг вважав це вторинним для основного бізнесу.

І ось тут на сцену вийшов молодий підприємець Стів Джобс. У ході свого візиту до PARC він побачив цей інтерфейс, був вражений і зрозумів, як це можна втілити в масовий продукт. Вже через кілька років Apple випустила Macintosh — перший комерційно успішний комп’ютер із графічним інтерфейсом.

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

Цікава історія від дружнього каналу про ретро компʼютери. Все починається як чергова історія старенької гри, але plot twist дуже неочікуваний 🙂

Ось візуалізація матриці 2 на 2 (або, як правильно підмітили у коментарях, матриці Ейзенхауера, про це можна і на сріні теж прочитати).

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

Важливість визначає, чи треба це робити саме вам, бо задача вимагає ваший особливих навичок чи вмінь.

Терміновість каже, чи треба це робити саме зараз або найближчим часом, або ж можна відкласти на потім.

Відповідно, алгоритм для обробки списка задач приблизно ось такий

Важливі термінові робимо самі (переглянути та затвердити звіт для стейкхолдерів для завтрашньої зустрічі)

Неважливі термінові делегуємо (якщо треба організувати зустріч зі стейкхолдерами, то доручаємо це асистенту)

Важливі нетермінові плануємо на потім (написати драфт пропозала для нового проекту, який запускаємо наступного місяця)

Неважливі і нетермінові просто викидаємо (черговий пост про Redis в телеграм канал писати не будемо, бо і так всі все знають)

Отже, пост про книжку. В неї трохи лякаюча назва, там є слово enterprise, яке може асоціюватись із бюрократією, сірими буднями і пенсією. І насправді, це так і було в часи, коли книжка писалась.

Тоді одним із підходів до побудови інформаційних систем (це те, шо зараз називають мікросервісами і клаудами) було використання такої собі enterprise message bus. Діди здригнуться, прочитавши назви Tibco, IBM WebSphere MQ чи Microsoft BizTalk. То були люті часи, ті системи коштували, як хмарочос, потребували команди сертифікованих адмінів і давали надію власникам бізнесу, шо "ось зараз заживемо". Програмісти не потрібні (або їх треба сильно менше), замість написання якихось своїх велосипедів треба просто робити XML, закидати його в шину, і читати, що там закинули інші. І тепер бухгалтерія дізнається, що там оприходували на складі, бо їхні системи інтегруються через шину.

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

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

Але це все не означає, що зараз ті всі рецепти втратили актуальність. Навпаки, рішення асинхронної взаємодії стали набагато доступнішими і більш функціональними. В кожному клауді є декілька рішень для черг. On premise теж можна використовувати безліч чудових продуктів. І для побудови сучасних стартапів це дуже привабливий архитектурний підхід. Адже асинхронна взаємодія набагато надійніша і гнучкіша, аніж стандартні RPC (remote procedure call) підходи.

На картинці видні усі патерни, що розказуються в книжці. Про них всіх можна почитати на сайті. Також сайт містить декілька прикладів реалізації messaging в сучасних клаудах. Дуже рекомендую як мінімум проглянути то все )

Ось посилання на сайт: https://www.enterpriseintegrationpatterns.com/patterns/messaging/

Натрапив на цікавий пост про чийсь досвід із проєктування фінансових систем. Ось вижимка для нетерплячих:

- 🌀 Уся обробка має бути ідемпотентною – ми не хочемо, щоб під час повторного запиту з рахунків знялися зайві кошти.

- 🗂️ Система має зберігати історію, а не лише кінцевий стан – привіт, друже event sourcing.

- 💰 Зберігати гроші потрібно в найменших одиницях:
- Якщо лише одна валюта (гривня), то в копійках.
- Якщо можливі конвертації – використовуйте DECIMAL(19,4).

- 🔄 Округлювати можна як завгодно, головне, щоб всюди однаково.

- 🔢 Конвертації краще робити в кінці розрахунків.

- ⏱️ Час зберігати в INT (unix time – це дуже потужна штука, я в Redis його використовую і дуже тішуся).

📌 Оригінальний пост з картинками і більше тексту:
Engineering principles and best practices

З розвитком карʼєри перед нами постає все більше різних компромісів. Один з них – це рівень експертності. Потрібно обирати — чи мати ширший кругозір, чи глибше закопуватись в конкретні технології. Бо насправді неможливо бути експертом в усьому. Зазвичай люди добре розбираються в тому, з чим вони напряму працюють. І рівень експертності поступово знижується, як тільки безпосередня робота припинається.

За свою карʼєру я був експертом по Delphi, MS SQL, .NET, Kafka. Тому що постійно працював з ними, слідкував за оновленнями, стикався з проблемами, вирішення яких підвищувало мій рівень експертності. Але зараз звісно не на всі питання зможу відповісти (а деякі може і не зрозумію взагалі).

Проте коли ви отримуєте сеньйорні позиції, від вас очікують саме експертності в усьому. І тут треба бути обережним. Доволі наївно вважати себе розумнішим за усіх інших. Скоріш за все, серед ваших підлеглих є більш прошарені у певних технологіях. І краще вибудувати такі відносини, коли ви могли покладатись на їхню думку у певних аспектах. Бо реальна сила менеджера полягає у вмінні делегувати. Чим більше делегуєте (правильним людям), тим більше обсяг роботи можете закрити і тим ціннішим ресурсом для компанії ви є.

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

Що думаєте?

Ще трошки #реклама від партнерів для тих, хто хоче прокачатись

🦾 Не відкладайте карʼєрний розвиток у розробці та архітектурі ще на рік — придбайте сертифікат на навчання зі знижкою до 40% на всі ІТ-курси від robot_dreams.
⠀
Серед курсів, які вже є в розкладі на 2025 рік:

🏃🏻Golang для розробників — навчитеся створювати високопродуктивні програми на Go

🔧Docker & Kubernetes — опануєте інструменти контейнеризації та оркестрації, щоб прискорити розробку та забезпечити стабільність інфраструктури

🔗Архітектура високих навантажень — опануєте сучасні практики з хайлоаду та системного дизайну, що застосовують у великих компаніях

♾️DevOps — опануєте всі потрібні інструменти й технології для автоматизації розробки, налаштування софту і підтримки його робочого стану

⚙️Чистий код і патерни проєктування — навчитеся рефакторити код та швидко опануєте 30+ патернів проєктування

Плануйте своє навчання у 2025-му році:
👉 Купуєте сертифікат до 31 грудня
👉 Обираєте напрям та курс
👉 Підключаєтесь до навчання та зростаєте в розробці й архітектурі

Більше курсів та деталі акції ⬅️

Гарна інфографіка від bytebytego про kafka. Ніколи не користувався flink до речі, а ви?

(ще трохи інфоциганщини, бо пʼятниця)

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

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

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

Краще бути ефективним підлеглим, ніж ефективним менеджером. Хтось може побачити тут заклик до "жополизання", але це не так. Якщо менеджера ви не влаштовуєте, то пофігу, що команда вас обожнює.

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

Ставте підлеглим чіткі задачі, і завжди упевнюйтесь, шо вони їх розуміють. Аналогічно прояснюйте запити від менеджера. Ідеально, коли все записане, строки вказані і можна відслідковувати статус без спеціальних сінків. Впровадьте якийсь інструмент (або домовтесь зі своїм менеджером).

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

Шо ще?

Я все ніяк не почну проходити цього річний Advent of Code, натомість (трохи з заздрістю) дивлюсь, як це роблять інші. І знову хочу нагадати вам про канал Сіпласпластик, який мало того, що регулярно постить по мотивам AoC, а ще й розвʼязує задачі на різних мовах програмування, і по його постам можна скласти враження про них.

Прямо як книжка 7 Languages in 7 Weeks в форматі телеграм каналу.

https://t.me/cpplastic/361

Замовники часто приходять із готовим рішенням, замість того щоб описати проблему, яку вони намагаються вирішити. Ось типовий приклад з адмінським UI:

Ситуація
Замовник каже: “Нам потрібен дашборд з таблицею, де буде 15 стовпців, 5 фільтрів і можливість експортувати все у PDF та Excel. Зробіть, будь ласка (тобто бігом).”

У чому проблема?
Замовник вже запропонував рішення: “таблиця з 15 стовпцями та фільтрами”. Однак він не пояснив:

• Чому саме 15 стовпців?
• Які дані найважливіші для користувача?
• Що насправді потрібно досягти з цим дашбордом?

Що потрібно зробити?
Замість беззаперечного виконання, потрібно повернутися до проблеми та зрозуміти вимоги:

Питання до замовника:

Для чого потрібен цей дашборд? — Щоб побачити ключові метрики чи знаходити певні аномалії?

Хто буде користуватися цим дашбордом? — Адміністратори, аналітики чи менеджери?

Які дії ви очікуєте від користувачів після перегляду цих даних? — Прийняти рішення, надіслати звіт чи щось інше?

З’ясувавши проблему, можна запропонувати більш оптимальне рішення:

• Замість таблиці з 15 стовпцями — зведені метрики у вигляді віджетів, щоб ключові дані були одразу видимі.
• Для глибокого аналізу — можливість фільтрації та розширення таблиць за потреби.
• Оптимізувати експорт, додаючи лише потрібні дані.

Результат:
Адмінське UI стане зручнішим, ефективнішим і буде вирішувати реальну проблему, а не “втілювати” готове рішення замовника.

попросили поділитись цікавою ініціативою, а я і не проти

Найкращий час для творення змін — сьогодні.
Бо освіта не чекає, а життя — тим паче.

Запрошуємо молодь долучитися до інтелектуального волонтерства та здобути досвід викладання із користю для українських школярів.

Програма «СтудМентор» — це програма волонтерства та розвитку, в якій українська молодь вивчає менторинг та застосовує його для викладання шкільних предметів у онлайні для дітей з прифронтових регіонів.

Умови участі:
📌 тобі 18-35 років;
📌 ти маєш глибокі знання з одного зі шкільних предметів;
📌 готовий/а приділяти програмі 4+ години залученості на тиждень;

Формат:
📌 уроки з учнями відбуваються онлайн, двічі на тиждень, по 45 хвилин;
📌 один/а ментор/ка викладає для 1 або 2 груп учнів (одна група — до 3 дітей 5-11 класу);
📌 команда «Навчай для України» забезпечує менторів/ок усіма матеріалами для викладання та постійним супроводом вчителів із досвідом.

Долучитися до програми можна за посиланням: https://forms.gle/fzMFrve5Nxr7wWNcA

Гарна інфографіка про API security. Єдине що хочеться додати — в багатьох випадках для веб застосунків API взагалі не потрібен.
Але це тема для майбутніх постів.

У вихідний день хочу порекомендувати (в черговий раз) цікавий канал, це є і про розробку і про селф менеджмент. Зокрема цей пост про зіро інбокс.

http://t.me/stendap_sogodni/176

Я колись писав, шо не люблю slack і jira / confluence. Бо вважав це унилим enterprisом, і коли в мене зʼявилась можливість, запустив процеси на discord і notion. Це було прикольно, обидва інструменти цікаві, були певні моменти, проте все вирішувалось.

Але життя занесло в ще один сетап, в якому (surprise, маза фака) той самий starter pack поміркованого стартапера. І я такий "oh shit, here we go again" почав то все використовувати, і... зрозумів, шо воно доволі прикольне.

Slack додав собі з останнього часу, як я його бачив, купу цікавих штук, чим стає дуже схожий на Notion. (Хоча мабуть насправді на teams, але не будемо згадувати його всує). Списки задач з делегуванням, канвас, де можна написати шо хочеш, зручний механізм відслідковувати свої заборгованості через нагадування – і це все навіть без сторонніх інтеграцій. Завести різні канали, типу сповіщень інфраструктури чи ще чогось, завжди було легше в слак. Єдине, що не можна процитувати частину повідомлення у відповіді, але фіг з ним – треба ж кудись рости.

Jira в cloud версії теж прикольна. Без дурних кастомних workflow, зайвих полів, на дефолтному сетапі там все зручно. Аналіз беклогу, підсвічування проблемних задач — зручно. Якісь нові кнопочки, пункти меню, доволі нормальна тема.

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

Кароч, я тепер поціновувач і слаку і jira. Кидайте помідори в коментах.

Супер книжка (її ще називають "книжка з мостами", що ставить її в ряд до "кабанчика", "планера" і інших культових книжок), яка відносно стара, але не втрачає своєї актуальності. Для мене вона фундаментальна, бо свого часу відкрила абсолютно інший підхід до архітектури — message driven. Бо до цього в голові була лише модель синхронної взаємодії, коли один сервіс викликав інший, так само, як один клас викликав інший. До речі, OOP, який більшість з нас знає, насправді "неправильний", бо оригінальна ідея, реалізована в SmallTalk передбачала саме асинхронний обмін повідомленнями між обʼєктами, а не прямі виклики. Принаймні, це моє розуміння, я не дуже вдавався в деталі, напишіть в коментах, як правильно.

А тут виявляється, що замість того, аби викликати інший сервіс, і із завмиранням чекати його відповіді, можна просто закинути кудись повідомлення. І відповідь на нього отримати теж, як повідомлення, через якийсь час.

Насправді ця модель більш точно моделює реальний світ. Адже усі наші взаємодії здебільшого асинхронні. Взагалі, синхронна модель здається набула поширення лише з виникненням електронних засобів звʼязку, коли можна швидко отримати відповідь. І чомусь ми стали вважати це дефолтним методом взаємодії, додали до цього транзакційність, і подубували такий собі делулу світ.

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

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

Так, хотів написати про книжку, а натомість мене винесло на філософію про messaging. Будемо вважати це вступом до наступного посту, який вже буде про книжку 🙂

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

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

Я особисто заношу або просто у daily note обсідіану, якщо я за компом. Або створюю нотатку в notes, якщо я з телефоном. Або просто надиктовую в годинник, якщо на ходу і інші методи незручні.

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

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

Також, якщо ми щось делегуємо, потрібно прояснити свої очікування, особливо терміни, коли ми чекаємо результату. Я використовую для цього due date в задачах, або просто проговорюю та фіксую в себе цю дату. Це дає можливість виконавцю узгодити її зі своїм беклогом і якомога раніше повідомити про можливі ризики.

Таким чином я можу забути про цю задачу, і покластись на інструменти.

А ви шо? Розкажіть про ваш підхід

Подивився відос про інфоциган, і подумав "а чим я гірше". Тому вирішив написати пост про менеджмент і самовдосконалення, побачимо, скільки лайків він набере.

Коли я заходжу в новий проект (тут мав би бути прикол про рушник під ноги), дуже стрімко починає рости власний беклог. І те треба було б зробити, і те, а без цього ми і дня не протримаємось. Задачі накидується, і постає питання – а як то все приоритизувати?

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

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

Зустрічайте матрицю 2 на 2. Малюємо табличку 2 на 2. По горизонталі в нас буде оцінка важливості, а по вертикалі – терміновості. Для кожної задачі визначаємо, чи є вона важливою, та чи є терміновою, і по результатам закидаємо в табличку. І таким чином отримуємо кластери

- важливі / термінові
- неважливі / термінові
- важливі / нетермінові
- неважливі / нетермінові

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

Ось такий прикол. Для персонального обліку задач я використовую Obsidian, а як побудувати в ньому такий інструмент, розкажу в закритому каналі для своїх.

Що думаєте?

Кожного разу, коли я бачу, як розробники просять девопсів "налаштувати CICD" чи "налаштувати метрики або логи", то трохи ловлю крінжи.

Зрозуміло, що налаштування та підтримка інфраструктури це окремий скіл, і вимагати, аби одні і ті самі люди і писали код і підтримували оточення – це занадто, проте є і інша сторона. CICD це складова саме розробки. Усі перевірки, які там запускаються, ініціюються і використовуються розробниками. Тому розуміння механізмів, що надає та чи інша платформа (умовних github actions) дозволяє зробити це найбільш ефективно.

Десь використати готовий екшен, а десь написати свій скрипт, що буде відпрацьовувати і локально і на сервері. Той же самий precommit – є перевірки, варті запуску локально, а є такі, що не варті, бо вони займають час і все одно будуть повторені на сервері. Розробник це розуміє, бо працює з цим постійно і має певні очікування.

Так само і потрібна інфраструктура. Можна чекати, поки по твому тікету піднімуть умовний posgtres на EC2, налаштують доступи і ти зможеш робити локальну розробку. А можна підняти усе шо треба в compose і радісно навалювати годняковий код.

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

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

Звісно, що варто мати якусь межу, де розробник відступає і виходить девопс / SRE. Тюнити кубернетес, сетапити бекапи і налаштовувати кластери монги розробники точно будуть гірше за девопсів.

Шо думаєте? Де та межа?

https://t.me/cpplastic/354
Прикольний допис про мову програмування, якої я ніколи не чув. Може і вам буде цікаво почитати :)

До речі, робите Advent of Code? Я цього року трохи буксую, але розглядаю можливість пострімити трохи. Типа пізній врив, коли суєта вспокоїться, почати з перших завдань – такий собі слоупок режим.

Перша книжка, яка дала мені розуміння про проблеми (і рішення) розподілених систем була Release It! (можете погуглити, там планер летить на обкладинці). Ось декілька цікавих інсайтів звідти:

- Усі взаємодії з віддаленими сервісами повинні мати таймаут. При чому чим він менший, тим краще. Нескінченний таймаут підвищує ризик того, що у випадку проблем усі потоки вашого сервісу стануть недоступними;

- Насправді краще лімітувати будь-які ресурси, що використовує сервіс;

- Сервіси мають властивіть пропагувати свої проблеми на інших. Наприклад, якщо якийсь сервіс нескінченно утримує запити, то це може викликати проблеми у downstream сервісів (його клієнтів) — дефіцит потоків, бо усі буть зайняті очікуванням відповіді;

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

- Реалізовувати стратегію disaster recovery набагато краще на етапі проектування і розробки, аніж під час масштабного збою в продакшені. Закладайте захист від збоїв на самих ранніх етапах, проводьте хаос тестування, збирайте метрики.

А ви читали її? Чи може щось інше? Напишіть в коментах.

Я вже писав про це не раз і може не два, проте все одно періодично попадаються речі, які важко проігнорувати. І це знову пост про AI.

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

Проте я натрапив на пост про те, як цьому сервісу згодували документ, що складався з декількох сторінок, заповненими лише двома словами: Poopoo Peepee (какулі пісюлі). Внизу буде посилання на результат, і я вам скажу, що воно варто того, аби послухати.

Структурований діалог, чудово поставлені голоси у дикторів, розмова, яку мені особисто було цікаво послухати. З абсолютно дурного приводу. Але це контент, і набагато кращий за ті, що подекуди роблять люди.

Критики AI кажуть, що це не інтелект, він не вміє думати. Але ми бачимо, що він чудово вміє як мінімум це імітувати. І робить це так, що доволі важко відрізнити від контенту, що згенерують люди. Тобто, аби робити це, не треба вміти думати.

А може ми насправді так і думаємо? Просто ситуативно на основі контектсу (памʼяті) визначаємо нашу наступну думку токен за токеном?

Звісно, може це все постанова, результат або повністю зроблено, або ж відредаговано людьми, можете самі послухати і скласти свою думку: https://www.youtube.com/watch?v=gfr4BP4V1R8&list=LL

Трохи флекса з минулого. Колись давно, ще в часи windows, MS SQL і Delphi, до мене, як "тижайтішніка" звернулись знайомі з турфірми допомогти з прогою, яку вони собі придбали. Там така собі повнофункціональна CRM з турами, туристами і тд, все прикольно і працює, але була проблема з тим, що паперові документи воно генерувало не такі, як потрібно. Ну знаєте, ваучери, квитки, звіти тощо. А виробник чи то не хотів це міняти, чи було дорого, але як би там не було, вирішили покликати компʼютерного майстра, що живе поряд, тобто мене.

Виявилось, що там стек такий самий, що і в усіх: умовний Delphi / C++ клієнт та MS SQL сервер з базою. Сервак стояв на тому ж компі, шо і клієнт і все чудово працювало. Клієнт звісно не мав ніяких можливостей для розширення (плагінів тощо), але цього і не потрібно було. Оскільки всі дані були в базі, можна було зробити зовніше рішення для друку необхідних документів. Стандартне рішення було б використовувати якусь бібліотеку для репортів, типу CrystalReports (вибачте, якщо у вас тут звело олдскули), але в нього були недоліки. Кожен репорт у разі змін потрібно було б фіксити мені, компілювати, давати нову версію, надсилати її імейлом, а потім ще й траблшутити, чи точно нову версію запустили, чи стару 🙂

Я хотів мінімізувати підтримку і зробити максимально гнучке (і в той же час зручне) рішення. Тому обрав автоматизацію з MS Word. Ідея в тому, щоб зробити шаблон (це документ .dot), в якому буде весь необхідний текст і поля, які замінюються значеннями з бази. І кожен документ представляв із себе звʼязку шаблону з SQL запитом, який мав параметри, міг був дуже складним, дістати будь-що і зконвертити у потрібну форму. Шаблон містив поля, в які підставлялись значення з відповідних полей результату, що повертав запит.

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

Таким чином, використання готових інструментів – Word для роботи з текстом, T-SQL для своєрідних лямбд для кастомної логіки без компіляції і Delphi, щоб дати цьому всьому гарненький сучасний для тих часів UI – допомогло реалізувати елегантне прагматичне рішення, яке тішить мене до сих пір. Ось такі технології нульових.

Розказуйте, чи було у вас щось схоже 🙂

#реклама від партнерів. Розробити гру на курсах про патерни проектування звучить як мінімум цікаво :)

⚙️ Патерни проєктування — це не код і не мова, і навіть не алгоритми, але ідея розв’язання певних завдань.

Навчитися рефакторити код та швидко опанувати 30+ патернів проєктування ви зможете на курсі «Чистий код та патерни проєктування» від robot_dreams.

За 21 заняття ви:
🦾 навчитеся бачити недоліки коду та виправляти їх
🦾 познайомитеся з архітектурою складних enterprise-level систем
🦾 розберете всі патерни та познайомитесь з антипатернами
🦾 дізнаєтеся як організовувати асинхронний код

У фіналі курсу розробите гру з використанням вивчених патернів проєктування і додасте цей кейс у портфоліо.

Лектор:

Олег Фокін — Lead Software Engineer у GlobalLogic, що має понад 20 років досвіду в розробці програмного забезпечення.

Деталі, програма та реєстрація ⬅️

🎁 До 30 листопада у robot_dreams діє акція до «Чорної пятниці» — придбайте будь-який курс і обирайте ще один у подарунок

По коментам до останнього посту трохи здалось, що люди сприймають написане у чорно білому спектрі. Тобто або фреймворщик, що нічого не тямить у алгоритмах і струкутрах даних, або CS graduate, що програмує лише на leetcode. Але насправді моя теза були іншою. Спробую більше розкрити її у цьому пості — побачимо шо з цього вийде 🙂

Я вважаю, що для реалізації проектів потрібно розглядати найбільш ефективні методи і інструменти. Перевикористати щось готове у більшості випадків швидше і краще, аніж писати свою реалізацію.

Якщо треба зробити сайт, не потрібно писати свій рушій для цього, проксі, кеш або сторедж. Для високодоступного сервісу вже є готові рішення для оркестрації, моніторингу живучості, масштабування тощо. Коли бізнесу потрібно запустити свій магазин, навряд чи він хоче, аби розробники витрачали його кошти на написання чергового ecomerce клону. Коли додавання товарів у кошик робиться двома командами три спринти, а в кінці все одно є баги. Just get the job done.

В деяких випадках написання своїх велосипедів має сенс. Якщо ваша компанія заробляє на аутсорсі, то звісно, треба писати своє. Бажано довго і великою компанією. А потім ще й підписати контракт на підтримку. В моєму досвіді є компанія, яка отримувала дуже класні контракти завдяки тому, що мала свою платформу. Яка була дуже незручна для роботи, проте була добре розпіарена.

Або якщо вже все працює, гроші є, і видно, що можна десь щось оптимізувати. Тоді можна написати свій envoy, як це зробили в lyft, або kafka (вона здається з Linkedin, я не гуглив, виправте в коментах якщо ні.) І ці рішення будуть флагманами і можуть зробити вас відомими. Але навряд чи це стосується 90% людей, які це читають. Нам треба просто ефективно витрачати кошти наших клієнтів, а не флексити під "not invented here" синдромом.

Я вже писав колись про те, що програмувати зараз стало набагато простіше. Одним рядком вирішується те, що раніше потребувало пару екранів лютого байтолюбного коду. Навіть програмування мікроконтролерів доволі просте, а оновити прошивку можна з браузеру через bluetooth.

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

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

Не треба городити свої планувальники задач, бо інфраструктура дає можливість запланувати будь-що, давай свій код і розклад у форматі CRON і йди пити пиво.

Не потрібно думати за алгоритми консенсусів, split brain, транзакційності тощо, бо є готові рішення, які можна додати, як залежності і просто використовувати.

Ну і свої стореджи звісно потреби писати також немає, бо їх стільки, шо якщо і є проблема – то це обрати потрібний.

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

Що думаєте?

Розширення, яке дозволяє зберігати sqlite базу в полі таблиці postgres.

Саме той випадок, коли ми не питаємо "нащо", ми питаємо "як".

https://github.com/frectonz/pglite-fusion

Netflix на вихідних упав, Envoy був незадоволений, а я згадав про service mesh. Що це таке?

Service mesh — це підхід (патерн? парадигма?), який вирішує питання безпеки, спостережуваності та надійності в Kubernetes-кластерах. І головне — розробникам не треба нічого спеціального дописувати в код. Усе працює на рівні інфраструктури. Типовий Kubernetes-стиль. 😊

Як це працює?

У кожен pod (мінімальна одиниця деплойменту, яка може складатися з одного чи більше контейнерів) додається sidecar — проксі-контейнер. Через нього проходять усі вхідні та вихідні запити. Найвідоміший приклад — Istio, який використовує Envoy як sidecar.

Ці sidecars автоматично додаються під час створення pod’ів і об’єднуються в мережу, що контролює увесь трафік. Завдяки цьому реалізуються такі можливості:

🔐 Безпека: автоматичне шифрування трафіку між pod’ами через mutual TLS (mTLS).

📊 Спостережуваність: на ingress додаються W3C Trace-Context заголовки, які прокидаються далі через усі виклики. Траси записуються, наприклад, у Jaeger, даючи вам карту всіх запитів. Правда, треба трохи допрацювати код, щоб передавати ці заголовки в інших викликах.

⚙️ Надійність: такі патерни, як повтори або “запобіжники”, налаштовуються на рівні Kubernetes-маніфестів. Просто задайте таймаути, кількість повторів тощо — і вони почнуть діяти.

🚦 Контроль трафіку: можна налаштовувати canary-розгортання, A/B-тести, розподіл трафіку за версіями або навіть за вмістом заголовків.

Недоліки?
• Покриває лише синхронну взаємодію.
• Споживає додаткові ресурси та знижує продуктивність.
• Іноді може “падати” — чи то через конфігурації, чи то з інших причин (девопси кажуть, буває).

Чи популярно?
Service mesh — це цікаво, але в продакшені я бачив це не дуже часто. Хоча для великих систем із синхронною взаємодією — штука корисна.

А у вас є досвід із service mesh? Поділіться думками! 👇

А чи задумувались ви, чому в GitHub зміни називаються “pull request”, а не “merge request”?

Якщо ви працюєте з GitHub, то напевно створювали pull request (PR), щоб запропонувати свої зміни в репозиторій. На перший погляд, логічніше було б назвати цю дію merge request — адже мета PR полягає саме в злитті змін. Однак у назві криється більше, ніж здається.

GitHub побудований на системі контролю версій Git, і тут криється ключ до розуміння. У Git команда pull означає витягнення змін з віддаленого репозиторію у локальний. Аналогічно, pull request відображає запит: “Витягни мої зміни з моєї гілки та додай їх у основну”. Тобто автор PR запрошує власника репозиторію “запулити” (pull) його код.

Історично GitHub запровадив цей термін, щоб залишитися ближчим до термінології Git. Це допомогло розробникам легше зрозуміти концепцію PR і співвіднести її з добре знайомими командами git pull та git merge.

Інші платформи, наприклад GitLab, використовують термін merge request (MR). Це звучить інтуїтивніше: адже кінцева мета — злити зміни. Але MR ставить акцент на фінальній дії, тоді як PR фокусується на процесі: обговоренні, перевірці та перевірці змін перед їх інтеграцією.

Pull request підкреслює, що зміни є запрошенням до співпраці. Ви не просто додаєте код — ви просите команду його оцінити, залишити відгук і вирішити, чи варто інтегрувати. Таким чином, назва pull request ставить у центр уваги командну роботу.

Отже, навіть якщо “merge request” може здатися зрозумілішим для новачків, “pull request” — це відображення спадщини Git і духу відкритого обговорення, що стоїть за кожним внеском у репозиторій.

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

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

Натомість практикуються асинхронні патерни взаємодії, такі, як обмін повідомленнями через сторонніх брокерів. І от на таку штуку натягнути трасування може бути доволі проблематично.

Бо обробники запитів замінюються на обробники повідомлень, а у повідомленнях не завжди просто визначити той самий оригінальний TraceID. Одне і те саме повідомлення може впливати на стан багатьох різних сервісів (отримали інформацію, що на складі немає певного товару – треба прибрати його з фронту, і також треба щось зробити із замовленнями на нього. Остання операція може зайняти час, замовлень може бути багато, і запуститись вона може далеко не одразу). Тому не дуже зрозуміло шо має бути взагалі показано на трасі.

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

І наостанок додам, що існують продукти під назвою APM системи (Application Performance Monitoring). Хоча цей акронім насправді не означає певний продукт, а скоріше це процес. Проте також він вживається для продуктів, які інтегрують логи, метрики і трасування "все в одному". Той же самий DataDog, або Elastic Observability (що раніше називався Elastic APM).

Про них треба знати те, що
- вони існують
- вони коштують грошей (зазвичай багато)
- вони дуже зручні в користуванні
- їм є заміна, або open source self hosted, або вбудовані рішення вашого хмарного провайдера.

Мем вихідного дня, який нагадав що я колись планував написати пост чи серію про service mesh.

В минулому пості перелічили чесноти трасування, але чому ж воно так мало застосовується? Напишу свій досвід як використання, так і спостережень.

Це може бути дорого. Ви мабуть чули меми про datadog і суми, які компанії платять туди. Дуже легкий поріг входу, зручний UX підсаджують на гачок. А коли здається, шо без цього жити неможливо, а продукт росте, приходять доволі суттєві чеки.

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

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

Тому в більшості випадків використовують семплінг. Це коли замість трекати усі запити, виставляється %, який потрібно записувати. Зазвичай це десь 0.1%, але все залежить від вашого навантаження. З семплінгом можна отримати якусь статистику, проте виловлювати помилки стає складніше.

Бо якщо помилка виникне в третьому сервісі в ланцюжку викликів, потрібно, аби траса створилась у перших двох. Є рішення записувати трасу після викликів, але воно ще більше все ускладнює, як на мене (можу помилятись, виправте в коментах)

Ну і остання причина, що воно насправді не таке вже і критичне. Здебільшого трасування потрібно для визначення критичних затримок. Але їх можна діагностувати і іншими механізмами, які простіше впровадити. Це і кастомні (або вбудовані, шо ще краще) метрики, або ж прості лог записи з часом, які потім можна пошукати в кібані.

Поки писав, згадав про ще одну проблему і таку штуку, як APM. Але в цей пост вже не влізе, давайте вже в наступному.

Останній з трьох стовпів спостережуванності (а перші два це логування і метрики) — це трасування. Насправді розподілене трасування, і розглядається воно в контексті розподілених систем.

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

Або ж ви бачите, що час обробки повільний, і хочете знайти, на якому етапі воно не працює. Саме для таких випадків і придумали розподілене трасування.

Ідея в тому, що у вхідній точці обробки запиту формується його айді, яке потім прокидується в інші запити. Інші запити прокидують його далі, і додають в контекст свою інформацію. Це все пишеться у спеціальний сервіс, який потім агрегує дані і показує у вигляді гарненьких waterfall діаграм (ви могли їх бачити в dev tools браузерів). І там видно, хто кого і коли викликав, і як довго ці виклики тривали.

Наприклад, сервіс yoba зробив запис в postres за 10ms, а потім відправив повідомлення сервісу foobar, який успішно впав

Знову таки, зазвичай колгоспити нема потреби, є готові рішення і стандарти. Уся необхідна інформація для трасування описується в стандарті W3C Trace-Context. Є сервіси що збирають і агрегують цю інформацію (каноном серед них є Jaeger). Платні рішення теж це підтримують, як і клауди, де воно вдудовано в їх системи спостережуваності.

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

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

Зробив відео про те, як на дешеві китайські приставки поставити лінукс і обʼєднати їх у кубернетес кластер. Дешево і сердито, але прикольно і працює.

Відео знімав і монтував тиждень (а може і більше). Це виявилось складнувато, але мені сподобалось і далі буде ще.

https://youtu.be/R8VLUCvIIro

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

А сьогодні от попалось це, і я не зміг втриматись.

Продовження про метрики, або пара цікавих фактів.

Як метрики збираються? Зазвичай практикується pull модель. Це коли сервіс не передає кудись (в prometheus) свої метрики, а натомість виставляє їх по HTTP у текстовому вигляді. Тобто буквально є сторінка, зазвичай /metrics, де перераховані усі метрики і їх значення. А prometheus опитує (по науковому кажуть "скрейпить") ці сервіси з якоюсь періодичністю. Тому в конфігурації прописуються усі такі місця, куди йому треба дивитись. Звісно, є виключення і push модель, коли сервіси передають самі свої значення у prometheus, але вони доволі рідкісні.

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

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

Є різні типи метрик, але головна ідея в тому. що кожна одиниця має часову мітку, назву, значення (або набір значеннь) і набір текстових міток. Ось наприклад:

<якась дата> cpu_usage{cpu="cpu0", exported_instance="lupa", exported_job="truenas", instance="graphite-exporter:9108", job="graphite", kind="system"} = 4.040404

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

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

В prometheus є своя мова для запитів, називається PromQL і вона доволі гнучка і місцями складна. Опанувати її – ціла наука.

Перед тим, як робити свої запити варто познайомитись з PromQL, типами метрик і зрозуміти концепт. Бо, наприклад, кількість запитів збирається у типу даних counter, який постійно збільшується, і якщо ви хочете показати кількість запитів в секунду, то треба використовувати комбінацію функцій rate() і sum(). Причому у правильному порядку, бо інакше дані будуть неправильні. А ви цього і не помітите.

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

#реклама last call на курс про високонавантажені системи

⚡️12 листопада у robot_dreams стартує курс «Архітектура високих навантажень» з Олегом Муравським, Principal Data Architect в eBay, який має 20+ років досвіду розробки ПЗ.

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

У програмі курсу — 16 занять, 11 домашніх завдань, та курсовий проєкт.

Після курсу ви:
✔️ вільно розроблятимете високонавантажені системи
✔️ обиратимете відповідне архітектурне рішення залежно від вимог до продукту
✔️ навчитеся адаптувати технології до конкретних вимог і завдань бізнесу
✔️ створите власну систему, здатну витримати щоденний трафік в ≥ 1 млн користувачів та масштабуватися

Детальна програма та реєстрація 🔗

Продовження серії про спостережуваність, і цього разу поговоримо про метрики.

Метрики – це усілякі числові показники, що змінюються з часом, які можна збирати і аналізувати. Завантаженість процесора, використання памʼяті, кількість або частота запитів – усе це метрики.

Для роботи з метриками вже все придумано до нас. Придумали навіть спеціальний тип баз даних, time series DB, які заточені саме під них.

Стандарт – це prometheus + grafana. Якщо спростити, то перший збирає, друга – показує (насправді і перший може показувати, і друга збирати, але в більшості випадків вони використовуються, як написано вище). У кожного є механізм для сповіщень, alert manager для prometheus і grafana alerting, які можна використовувати для нотифікацій, якщо певні метрики викликають тривогу.

Для більшості випадків достатньо знати ще терміни node exporter (збирає метрики з серверів), cadvisor (збирає метрики з контейнерів) і Service / Pod Monitors, які збирають метрики в кубернетесі.

Базовий набір метрико початківця такий:
- ставимо десь prometheus і графану
- на серваки ставимо node exporters
- в докери ставимо cadvisor в кубернетес сервіс монітори
- гуглимо гарні дашборди і додаємо їх в графану. Це максимально просто, потрібно лише вставити айді дашборди в UI графани і підключити відповідний промітеус.

Усі ці "ставимо" насправді є копіпастою yaml файлів з інтернету і робиться за пару хвилин.

В результаті отримаєте графану з гарними графіками, як на pic related (це скрін з моєї графани, яка запущена на кластері з ТВ приставок – про них на днях вийде відео на ютубі).

Зазвичай цього всього буде досить, але якщо хочете більше деталей, то у наступному пості трішки заглибимось у деталі.

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

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

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

В коментах було декілька прикладів, які мали на меті показати перевагу структурованих логів. Наведу приклади, чому ця перевага не настільки вирішальна.

Пошук по індексованим полям відбуваєтся швидше і дає менше навантаження на еластік. Це правда. Проте еластік доволі ефективно вміє шукати по тексту. І такі випадки одиничні, ми ж не говоримо про десятки чи сотні таких пошуків в секунду, вірно? Бо якщо ми так часто шукаємо причини помилок, то мабуть замість оптимізації логінгу варто зайнятись їхнім фіксом?

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

Розпарсити JSON простіше, ніж паритись з регулярками. Теж правда, проте паритись з ними може і не треба. Більшість форматів вже відома, їх можна нагуглити, і накрайняк ChatGPT підкаже правильний регексп. І знову таки, це одиничні операції, якщо у вас команди мають певний стек, то і в усіх сервісах буде однаковий формат. І не варто забувати про сторонні сервіси, сайдкари, бази, проксі і тд, які не в джейсон форматі. З ними все одно треба шось робити (і дуже рідко коли я бачив, щоб девопси переводили логи кубернетеса в json). З такої позициї вигідніше розглядати усі логи як plain text і будувати свою стратегію на цьому.

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

По кількості дизлайків до попереднього посту можна вирахувати, скільки є девопсів у підписниках.

Є такий чудовий термін observability, або ж спостережуваність. Він означає властивість системи, що дозволяє зрозуміти її внутрішній стан на основі зовнішніх даних, які вона генерує. Складається з трьох компонентів: логи, метрики та відстежування (tracing). Цей пост буде про перший з них.

Логи є мабуть найзрозумілішим з цих компонентів. Текстові повідомлення, які пише наш (або чужий код), і по яким можна спробувати зрозуміти, шо відбувалось і що пішло не так. Є купа бібліотек для логування, як і транспортів. Їх можна писати в кафку, базу, на зовнішній сервіс і тд. Моя особиста порада (для бекенд) – триматись якомога ближче до дефолтів, і писати в stdout (в консоль). Чому так? Тому що зазвичай ваші сервіси будуть працювати в середовищі, де є механізми збору логів з stdout, а також усі необхідні перетворення, доповнення і так далі.

Stdout завжди працює. Якщо відвалиться база чи черга, куди ви пишете логи, то ви про це не дізнаєтесь, бо логів не буде ) Також можна писати / дублювати у файли, проте у більшості випадків цього не треба робити.

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

Є адепти структурованих логів, які вимагають, аби усі логи писались в JSON форматі. Бо їх легше оброблювати і можна додавати різні метадані. які потім зручно використовувати для запитів. Наприклад, id користувача, номер замовлення та інше. Я доволі прохолодно відношусь до таких вимог, бо вони, як правило вимагають відходу від дефолтів, налаштування форматерів і додавання зайвого інфраструктурного коду. Для мікросервісів це означатиме нові залежності, які треба підтримувати, якось мігрувати (новий архітектор запропонував змінити структуру джейсона, шо робити з існуючими сервісами) і тд. Суцільний геморой.

В той же самий час я не бачив де б ці структурні речі дійсно зарішали. Бо якщо вам треба знайти логи по номеру замовлення, то можна просто використати повнотекстовий пошук з цим номерам. А робити якийсь репортинг по логам (group by order_id в Kibana) — то ще та дикуха (якщо треба деталі – пишіть в коменти, розкриємо тему).

Ще одна причина, чому не варто очікувати всюди JSON логів (та і взагалі уніфікованого формату), це те, що у міксі ваших сервісів не лише ваші. Різні кафки, трефіки, і інші пострегси теж пишуть свої логи, на які також хочеться подивитись. А підігнати їх під ваш формат – це задача із зірочкою (і з нульовим вихлопом). Тому краще просто вміти агрегувати логи незалежно від формату.

Якщо ви в клауді, теж варто почати з їх вбудованого рішення. Зазвичай його вистачає надовго (в плані грошів), воно легко інтегрується, і підтримується іншими клауд сервісами.

Тому просто пишемо в stdout, використовуючи дефолтний логер (або якийсь хіпстерський, який налаштовується одним рядком), а решту розгрібаємо на наступних етапах. Іншими словами – хай девопси паряться.

Шо скажете?

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

Хтось може сказати, що Docker це і є контейнери, але це не зовсім так. Контейнери існували ще до появи docker, і навіть мають різну реалізацію. В bsd системах вони називаються jails, тобто фраза "10 год тюрми" для поціновувачів BSD систем може нести інший зміст.

Можна думати про контейнер, як про полегшену віртуальну машину, і це теж доволі умовна аналогія. Насправді це комбінація неймспейсів і контрольних груп лінукса. Якщо ці терміни вам нічого не кажуть, не біда – 90% розробників далі не заходять і їм досить цього знання. Суть в тому, що система надає можливість ізолювати процеси і ресурси, і на базі цієї можливості працюють контейнери.

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

Але шо ж тоді doсker? Це продукт, який зробив використання контейнерів зручним. Тулінг, який включає формат файлів для побудови контейнерів і набір утиліт для керування ними. Також включає compose, який дозволяє описувати набір контейнерів у декларативному форматі, що зручніше за CLI.

Окей, а кубернетес? Це інструмент для оркестрації контейнерів. Його ідея в тому, щоб забезпечити безпроблемну роботу контейнерів на кластері, що складається з декількох (або багатьох) фізичних чи віртуальних серверів. Користувачу достатньо описати бажану конфігурацію (ось такі контейнери, кількість реплік, налаштування доступу), а кубренетес їх запускає, перезапускає, якщо вони впадуть, перезапускає, якщо фізична нода перестає працювати, і робить багато іншого. Виглядає, як приватний клауд, який знімає потребу з ручної координації сервісів.

Це так само не єдине і унікальне рішення. У докера є swarm, який вирішує ту саму проблему. Але кубернетес це саме популярне, і своє знайомство з оркестраторами варто починати саме з ним.

У твітері натрапив на чудовий пост про виклики, що постали перед розробником розподілених систем, переклав його для вас:

Коротше, я вже реально втомився від того, що люди кажуть, ніби моєму додатку для контактів не потрібна повноцінна мікросервісна архітектура. Перейшов з $8 на $48-доларовий сервер, бо, ВИЯВЛЯЄТЬСЯ, що запуск Elasticsearch, MongoDB, Postgres, Redis, Kafka з повним зберіганням подій використовує “забагато пам’яті”. І що вони від мене хочуть? Зберігати номери телефонів в одній таблиці? Як якийсь аматор??

У моїх діаграмах 16 різних сервісів, і так, кожен з них потребує власної бази даних. Клієнт постійно питає, чому збереження контакту запускає 47 фонових задач, але вони просто не розуміють найкращих практик. Постійно отримую OOM, навіть якщо немає жодного користувача, але це очевидно через те, що health checks від сервісмешу генерують забагато подій (кожен ping health треба зберегти в 3 базах даних для узгодженості). Так, додаток зараз крашиться, але це тільки тому, що треба більше RAM. Можливо, доведеться перейти на $96-сервер, щоб впоратися з навантаженням на запис, бо кожна CRUD-операція зберігається як незмінна подія.

Якщо у когось є рішення, які не передбачають видалення мого service mesh або пропонування SQLite, я відкритий до пропозицій. І ні, “спростити” не варіант. Не для того я 6 років вивчав розподілені системи, щоб будувати примітивний легасі моноліт із минулого століття.

.... наступний пост:

Оновлення: клієнт розірвав мій контракт, бо “не зміг розібратися з кодом” і “навіщо нам Kafka для зберігання 5 номерів телефону”. Лузери. В будь-якому випадку мій технічний пост про патерни enterprise-управління контактами на підході.


P.S.: вони також відмовилися дати мені переписати все на Rust. Якщо чесно, я лише уникнув проблем.

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

Втомилися від низької конверсії лідів у 3-5%? Чи зростає ваш CAC на 55% щороку? А найголовніше — постійні брейншторми з командою не допомагають зрозуміти, як підвищити ефективність продажів і знизити витрати?

Дарина Басараб поділиться багаторічним досвідом роботи та допоможе знайти правильні рішення до цих проблем на вебінарі, який відбудеться 7 листопада.

Реєстрація за посиланням:
https://forms.gle/JJeDvB43gKJiutkHA

Чим цей вебінар корисний для вас:
1) Як збільшити конверсію лідів. Як впровадження системи скорингу лідів може підвищити вашу конверсію до 20-30%? Ми навчимо вас, як персоналізувати комунікацію та оптимізувати процес кваліфікації.

2) Як знизити CAC. Дослідження показують, що середній CAC у B2B бізнесах зріс на 55% за останні 5 років. Ви дізнаєтеся, як аналізувати та оптимізувати канали залучення клієнтів для зниження витрат.

3) Customer retention  це новий Customer acquisition. Втрата навіть 5% клієнтів може знизити прибуток на 25-95%. Ми розкажемо, як збирати зворотний зв'язок і впроваджувати програми лояльності для підвищення retention.

4) Наслідки короткострокових контрактів. Короткострокові контракти призводять до зниження LTV клієнта на 30-50%. Як розробити ціннісно-орієнтований процес продажів?

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

Не пропустіть. Реєстрація за посиланням:
https://forms.gle/JJeDvB43gKJiutkHA

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

На одному з останніх стрімів почав це робити. Як то буває на стрімах нічого нормально не виходило, і лише під кінець я знайшов (насправді згадав) правильний helm чарт і справа пішла, графана залетіла, і на тому все призупинилось.

Я залишив усе як є, аби подивитись, наскільки воно стабільно. Бо ставив я усю кухню на кластер з китайських ТВ приставок, на яких запущено armbian. І чомусь переживав, шо графана буде заважкою. Але ніт, все тихенько працювало, не падало, показували внутрішні метрики і усіляко спонукало на наступний крок.

І от я його зробив. Додав на пупу cadvisor і node exporter. Також підняв там окремий prometheus (може і дарма, але най буде). З цього всього отримав метрики по ноді і усім докер контейнерам. На лупі стоїть TrueNAS, він чомусь не вміє в prometheus, а лише в Graphite, тому довелось підняти його на пупі (бо компоуз), після чого налаштував туди експорт. В результаті є метрики по TrueNAS.

Шо ще є? Роутер з OpenWRT. Виявляється і з нього можна зняти метрик, поставив пару пекеджів з експортерами, завів їх на prometheus пупи, звідти в графану.

В результаті купа дашбордів, циферки, графіки – є усе. На цьому треба було б зупинитись, але ніт.

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

Але це може і добре. Бо цього разу можна буде автоматизувати і може зробити з цього контент на ютуб. Вам же цікаво подивитись, як з телеприставки за 2500 грн можна зробити лінукс сервак, а потім зібрати декілька штук у кубер кластер?

Хоча насправді треба робити бекапи...

В мене в планах серія технічних постів про мій проект, але сьогодні черга ось цього.
У твітері один пан написав щось типу "побачив, шо людина, якою я захоплювався, як висококласним технічним спеціалістом, використовує ChatGPT, і це мене засмутило". Мовляв "я думав він крутий, а він у чата питає те, шо я і так знаю". І мене це трохи тригернуло.

Бо для мене чат це лише інструмент. Такий самий, як редактор, чи IDE, чи компʼютер, чи Google в кінці кінців. Пригадався кейс, коли запускався Uber в Лондоні, то це викликало обурення серед водіів таксі. Бо їм потрібно було вчитись півтора року (чи шось таке) і знати напамʼять усі вулиці. А тут якісь позери ставлять апку, вішають телефона на панель тачки і починають робити їхню роботу.

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

Колись один чувак казав, що справжній програміст має вміти написати драйвер. А я зараз кажу, шо це булшіт. Бо можна бути класним програмістом і не знати, як ті драйвери працюють. Натомість робити highload розподілені системи на сотні тисяч користувачів.

AI для програміста покращує багато напрямків: дозволяє швидше знайти (чи пригадати) потрібну інформацію, надасть потрібний контекст, чи нагенерить бойлерплейт. Це все прискорює роботу, і дозволяє закривати задачі швидше. А хіба саме не швидкість вирішення проблем (якісного звісно) визначає класс спеціаліста?

Шо думаєте, чи можуть користувачі AI інструментів вважати себе експертами?

Побачив у твітері опитування "що вас більше всього вразило за вашу айтішну карʼєру в сенсі технічного прогресу?" і подумав, шо це непогана тема для пʼятничного посту. Сьогодні ж пʼятниця?

Не забувайте, шо я дід, тому деякі речі можуть вам здаватись дивними, бо згадуватиму я доволі старі історії. Отже:

– Графічний UI. Я багато часу провів у текстовому режимі (DOS і побутові компи), відеокарти з графічним прискоренням були чимось надприродним, а ті що були (CGA, EGA, VGA) вимагали надзусиль для простих графічних операцій і були дуже повільними. Тому ідея малювати текст у графічному режимі для мене здавалась доволі амбіційною. Ще й шоб курсор там миготів – ну дурдом.

– Відео по інтернету. Знову таки, через обмеження технологій, прогрес яких відбувався на очах, можливість дивитись відео через інтернет здавалась фантастикою. Бо до того інтернету з дому ми підключались через модем і там було 56кілобіт (!) швидкості. Завжди було трохи сумно від розуміння того, шо усі ці стійки з серверами, проводами, свічами і роутерами потрібні для того, шоб ми дивились рекламу тему в ютубі.

– JVM / CLR. Віртуальна машина, в якій компілюється на ходу код джави чи сішарпа і виконується? Шо за додік це взагалі придумав? Я прийшов зі світу, де програми компілюються, і все одно повільно працюють, тому в них робили асемблерні вставки, і ніяк не міг зрозуміти, як можна так марно тратити ресурси процесора.

– Python. Трохи шкода вбитого часу на пошуки ідеальної мови, коли вона завжди була поруч. Але нічого, так ви хоч зможете посміятись з моїх недолугих спроб програмування на стрімах. Ви ж ходите на мої стріми?

Пишіть те, що вразило вас в коментах

З вами буває таке, шо побачили якусь думку, пройшлись по діагоналі, трігернулись на якісь слова, і написали свій комент? А потім виявилось, шо комент не дуже валідний. В мене таке буває, останній раз трапилось ось з цим постом (підпишіться на канал BTW).

Тригернуло серед всього іншого твердження про те, що PATCH неідемпотентний. В моїй голові HTTP verbs матчаться на CRUD, і PATCH / PUT обидва презентують UPDATE, який по своїй природі ідемпотентний. Проте, я поліз читати інтернет і побачив такий от пост від Mozilla, де пояснювалось, чому PATCH все ж не обовʼязково є таким.

Річ в тому, що PATCH оновлює частину ресурсу, в той час як інші частини ресурсу можуть оновлюватись іншими механізмами. В оригинальному пості приводиться приклад, коли PATCH робить автоінкремент. Мені особисто такий сценарій здається дивним і не дуже доречним. Хоча в MDN статті теж йдеться про автоінкремент, проте в іншому контексті.

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

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

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

Але тепер принаймні я буду знати, що такий авторитетний ресурс, як MDN, вважає PATCH неідемпотентним. І ви також.

Задумав додати на сайт google analytics. Наче зробив все за інструкцією, але у консолі не бачу ніяких даних. Спочатку подумав, шо може треба дати йому 100 днів деякий час на роздуплитись.

Проте пройшло півтори доби, а даних все ще немає. Сайт треба запускати в дикий світ, тож вирішив розібратись шо там відбувається. Запускаю dev tools і бачу там uBlock Origin - a browser extension to block requests. А після цього згадую, що користуюсь бразузером Brave, в якому вбудований блокувальник реклами.

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

Але тепер я думаю, шо збрати статистику по відвідуванням сайту стало складніше. Бо мене мабуть цей сайт і не помітив. Тому що і на мобіли в мене браузер від duck duck go, який теж блокує трекери.

Доведеться згадувати старі добрі часи і додавати ручний трекінг в базюльку. Чи може є щось готове? Підкажіть.

І до скандально таблоїдних новин. Є такий дядько, Річард Столмен. Він – засновник GNU проекту і взагалі видатний діяч опенсорс двіжу. У нього доволі прикольний сайт, https://www.stallman.org/ – такий собі олдскул. З часом він нагенерував багато різних думок, які місцями доволі контроверсійні.

Нещодавно зʼявився інший сайт, stallman report. В якому анонімні автори занотували усі спірні твердження Столмена, і звинуватили його у різних гріхах. Про це зняв відео Bryan Lunduke, це інший цікавий дядько, який останнім часом викриває різну (переважно лівацьку дічь, як то з GoDot, перегіби з діверсіті в опенсорс спільнотах і тд.). І в тому відео він вказав, шо звісно є за шо критикувати Столмена, і він сам неодноразово це робив, в тому числі і висловлював свою критику персонально самому адресату. Але сайт робить це анонімно, і це дикуха.

А потім, за пару днів, вийшло інше відео, де Браян деанонімізував автора репорта. І зробив це, використовуючи сервіс, який показує інфу по DNS. За допомогою цього сервісу він виявив, що IP сайту з репортом раніше співпадало з IP персонального сайту ймовірного автора. Такий от OSINT. Я не знав про такий сервіс, може і вам стане в нагоді.

Деталі у відео: https://lunduke.locals.com/post/6235945/drew-devault-behind-stallman-report-org-hit-piece

От дивлюсь на ютубі відео, де козаки сетаплять серваки. Такий собі хардкор – серваки з початку нульово-десятих, в яких всередині є інший комп, на який можна зайти навіть коли сервер не увімкнений, продіагностувати його і запустити, наприклад. І от чувак його показує і каже "воно коштувало 10 кілобаксів і у якогось small to medium бізнесу уся інфра працювала на такій залізяці". Налаштування займало години, а може і дні, і взагалі було як ремонт, який ніколи не закінчується.

А я подумав, що для мене це все незвично звучить. Бо я, як хлопчик, вихований кубернетесом, сприймаю сервери, як щось ефемерне. Зараз воно є, а потім його нема, а ще потім знову є. Замість серверів в голові сервіси, які піднімаються і гасяться, переносяться з одного хосту на інший – і це все відбувається саме по собі.

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

Таку зміну парадігми називають, pets vs cattle. Pets – це домашні траринки, котики та собачки, кожен з яких це індивідуальність, має імʼя, свою мисочку і тд. Так само і раніше сервери називались іменами із зоряних війн чи матриці, ходили по SSH дивитись логі та накатували апдейти. А cattle – це домашня худоба, стадо овечок чи курки на птахофабриці, які для ідентифікації максимум на шо можуть розраховувати, так це на літеро-числовий ідентифікатор. Так само, як сучасний fleet серваків, додані в ansible роль.

Мені трохи не вистачає тієї ламповості. Може тому, що я особливо її не застав, бо якось не доводилось адмініструвати серваки. А зараз це якось цікаво. Тому маю home lab з пупами і лупами. А у вас є homelab? Розкажіть.

Дивіться, який скарб. Український переклад книжки про історію small talk від активного учасника нашого чатика.
Small Talk це правильний OOP, а не те, шо ми собі всі уявляємо (C++, Java, C# і тд)

Ось пряме посилання, якщо боїтесь чатику

тоді раз книжки не читаєте, може про справжне ООП від Алана Кея прочитаєте?

https://kant2002.github.io/EarlyHistoryOfSmalltalk/

Ви не задумувались, що все більше речей, які ми купуємо, насправді нам не належать? І не лише те, що купуємо, а і те, що створюємо. Фотки в хмарних сервісах, документи, фільми, книжки, ігри. Ми платимо гроші, отримуємо їх, але по факту не володіємо.

Можете сказати, шо це все просто доколупування до термінології. Бо яка різниця, коли ми можемо ж взяти і почитати книжку, або подивитись кіно чи пограти в гру. І дійсно, в більшості випадків немає ніяких проблем. Проте тут ситуація, як з авіалініями: все добре, поки йде по плану, і все стає жахливим, коли плани порушуються. Ось вам декілька прикладів

- гугл забанив і видалив акаунт чувака через те, що той надіслав фото своєї дитини своєму ж лікарю для консультації. Алгоритми побачили в цьому злочин, і все, прощавай усе
- мене колись забанив інстаграм незрозуміло за що. Це був новостворений акаунт, я пробував запустити hello world з їх апі, отримав бан.
- амазон вилучив книжку 1984 в усіх користувачів, що її "придбали", через те, що видавець порушив якісь права. Нічого нікому здається не відшкодовували.
- є випадки, коли книжки в електронній бібліотеці змінюються через різні причини, і не завжди користувачі, які "володіють" ними, можуть цьому завадити.
- історія, коли гугл необачно видалив аккаунт хедж фонду
- різні історії з банами за порушення різних правил steam / інших сервісів з втратою усієї бібліотеки без відшкодування
- бан акаунту у соціальних мережах і інших ютубах, з видаленням вашого наче "власного" контенту

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

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

Шо думаєте?

Чомусь скандали і інтриги набирають більше уваги, ніж технічний контент. Хоча зрозуміло чому, шо це я )

Тому ось що несеться останнім часом

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

- загроза зникення io домену протягом пʼяти років. Нещодавно була новина, що Велика Британія віддала якісь острови іншій державі (про яку я і не чув). А ті острови виявились Indian Ocean islands, територією, що володіє тим самим io доменом. І за процедурою він має зникнути. Там все складно і повільно, і скоріш за все нічого не зміниться. Але все одно цікаво

- демарш Godot. Це – ігровий рушій, доволі популярний і опенсорсний. Скандал виник після того, як у соціальних медіа його представники почали нагоняти політичну повісточку про діверсіті і тд. А коли їм зауважили, шо може краще давайте пофіксимо багі, то дуже агресивно накинулись на усіх незгодних. В результаті перебанили купу людей, включаючи спонсорів. А комьюніті створили форки, самий популярний з яких це Redot.
Іронія в тому, що поки що Redot лише піариться і набирає фоловерів, поки що жодного релізу не було

Розкажіть, які скандали знаєте ви?

Коли ми вчили програмування, то дізнавались про алгоритми і структури даних. Які з них для чого підходять, і де що краще застосовувати. Проте, у професійному застосуванні нам зазвичай не треба реалізовувати алгоритм, наприклад, сортування. Бо його вже написано, і зроблено це оптимальним шляхом. Покращити там навряд чи вийде, і найкраще це просто перевикористати його.

Коли ми вчимо AWS (це приклад, можна взяти будь-якого іншого провайдера), то дізнаємось про різні IAM політики, ролі, security groups і так далі. Але коли починаємо це використовувати, то не дуже хочемо вдаватись в деталі налаштувань, а просто беремо вже готові, так звані "best practices". Бо нам треба просто налаштувати лямбду, яка буде слухати API Gateway, виконувати логіку і складати результати в DynamoDB.

Звісно, ми знаємо про minimal privilege policy, проте не хочемо вручну колупатись в десятках сутностей і їх параметрах. Ми хочемо просто "зробити все правильно" і піти пити пивко.

Якщо все робиться з GUI, то ці налаштування робляться за нас. Створюються неявні компоненти, відкриваються порти, додаються рули у файрволи.

А у випадку infrastructure as code замість десятків рядків детального опису інфраструктури ми обираємо один – два рядки з AWS CDK Solution Constructs. Це – високорівневі компоненти, що налаштовують взаємодію різних сервісів найбільш правильним чином. Один компонент під капотом створить десятки низькорівневих сутностей і налаштує їх оптимальним чином.

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

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

А якщо їх все ж таки немає, то варто переглянути свій план. Може можна підлаштувати його під те, що вже є готове?

"Знову проблеми на проді, був про це алерт?"
"Мабуть був, але ми його пропустили серед 100+ інших..."
"А чому ніхто не помітив, що цей графік скакнув догори?"
"Хм, він просто внизу, треба скролити графану, шоб його побачити..."

Знайома тема? Це здається абсурдом, але я особисто спостерігав схожі ситуації в декількох компаніях. Там були девопси, SRE, нічні чергування, L1-3 сапорти і тд. Купа дашбордів в графані, на кожній графіки, циферки, різнокольорові тренди. Алерт менеджери, канали в slack, нотифікації – усе це було, його було багато, проте все одно пропускались важливі сповіщення.

Чому так? Саме тому, що усього було забагато. Купа інформації, більшість з якої по суті це шум. Шум, який забивав корисний сигнал.

Що треба натомість? Простота. Дашборд, який має показувати статус системи має бути максимально простим. Ідеально – просто порожній бекграунд, або світлофор. Зелений, якщо все ок, жовтий, якщо щось не ок, червоний, якщо халепа вже настала. Бути на видному місці, щоб усі, чия реакція може допомогти, його бачили. Фізичний світлофор в кімнаті команди, монітори на стінах та інших помітних місцях.

Хтось скаже "і шо з того червоного квадратика? треба ж роздуплити в чому проблема". І це вірно. Тому такий дашборд має давати можливіть drill down в деталі, аби дістати більше подробиць. Ідея в тому, що треба рухатись саме в напрямку "бачу проблему – шукаю деталі", а не "бачу купу деталей – намагаюсь зрозуміти, чи є проблема".

Якщо нотифікації, то це мають бути лише нотифікації, на які потрібно реагувати. Коли в каналі з критичними повідомленнями зʼявляється таке, про яке кажуть "а, ну це періодично стається, нічого страшного, скоро попустить", це індикатор, що йому тут не місце.

Тому так, в данному випадку працює принцип "чим менше, тим краще", або "менше фігур – легше грати". Розкажіть, чи багато булшиту на ваших дашбордах і алертах?

запропонували поділитись анонсом безкоштовної події, а я і не проти
#реклама

24 жовтня ділитимемося практичними порадами щодо сучасних підходів до обробки даних, огляд інструментів та кейсів від провідних експертів у сфері Data Engineering.

Спікери розкажуть про рішення для архітектурних викликів даних у Redshift, уроки з впровадження Data Mesh з Kafka для 50+ команд, реалізацію фреймворку Data as a Product з AWS DataZone, відкриття даних у багатоаккаунтних середовищах AWS, помилки при плануванні архітектури даних та приховані недоліки AWS MWAA та багато іншого.

Що очікувати від нового розділу AWS Notes:

- 6 Tech Notes, де спікери поділяться своїм досвідом побудови та роботи із системами обробки та аналізу даних
- 2 короткі Snap Talks з концентрованими інсайтами про найсвіжіші технології та практики
- Формат: онлайн
- Час: 14:00 - 20:30 (GMT+3)
- Участь безкоштовна

З цієї нагоди ми збираємо разом провідних data експертів та сертифікованих AWS спеціалістів, серед яких: Юлія Шологонь з SoftServe, Тарас Сліпець з Flix, Alex DeBrie (AWS Data Hero), Joel Farvault з AWS, Ростислав Мироненко з Booking.com, Дмитро Сірант з OpsWorks та Максим Войтко з Honeycomb Software.

Для більш детальної інформації та реєстрації відвідайте сайт конференції: https://bit.ly/3YjdrzH

Колись я думав, шо причини проблем з моїм кодом – помилки компілятора. Бо інакше якого фіга мій геніальний код не працює?! Потім дізнався, шо існують космічні промені, які вибивають електрони з чипів памʼяті і це може призвести до зміни даних і, відповідно, спотворення результатів роботи програм. Але це все була фігня порівняно з тим, про що я розкажу нижче.

Виявляється, що процесори можуть просто неправильно рахувати. Ти в нього питаєш "шо ти, голова? скажи-но скільки буде 2+2?" А він такий: "пʼять!". Так, ось так тупо збреше, в стилі ChatGPT.

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

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

Сподіваюсь, я підкинув вам ще один вектор для параної (і обгрунтування, нащо треба більше серверів і чому вони мають бути новішими). Більше деталей і обговорень можна почитати на hacker news: https://news.ycombinator.com/item?id=27378624

Згадав ще один прикол. В мої олімпіадні часи арсенал програмістів був набагато скромніший.

Зі структур даних лише масиви і примітивні типи. Умовний list чи dictionary треба було писати з нуля. Сортувати масив – вручну, вкладені цикли, проміжні змінни і тд. Записати чи прочитати файл? Самопальні буфери, виклики низькорівневого апі і тд – рядків 20-30.

Тому простий сучасний oneliner "накидати в dict слова і їх кількість в тексті, відсортувати і взяти 5 найвживаніших" виглядало, як пара сотень рядків з байтомісівом, циклами з i + 1 та іншими низькорівневими розвагами. Обовʼязково зошит в клітинку, в яких малювали байти і розписували структури даних. "Тут індеси, а тут покажчики, а так будемо конвертувати одне в одне".

Зараз SDK та базові ліби сприймаються як буденність. Так само, як і виразність та потужність (а деколи і незламність – це я про rust) сучасних мов. Коли робиш Advent of Code, то прості brute force рішення пишуться за пару хвилин. Звісно, їх потім треба перероблювати, бо воно зазвичай не працює. Але раніше для того, аби написати просте рішення, потрібно було витратити купу часу. І це було доволі необачною інвестицією, бо часу, що залишався, могло просто б і не вистачити на допрацювання рішення.

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

Очевидно, що waterfall виходить з тих часів. Ітеративні підходи почали зʼявлятись лише тоді, коли технології почали це дозволяти. І зараз набагато ефективніше навалити якогось коду, може не дуже оптимального, негарного, який не сподобається ревьюверам. Але який може просто працювати. Отримати baseline, і вже його поступово покращувати. Швидкі ітерації зі зворотнім звʼязком замість довгого і нудного планування.

Мені подобається працювати саме так. Замість довго думати і планувати в голові, як той код буде працювати – просто написати його, запустити і подивитись, шо з того буде. Замість тримання в голові різних edge cases просто описати їх в тестах. Тести зелені – проблем нема. Є проблема – пишемо тест і робимо, шоб вони знову стали зеленими.

Тому я дуже тішусь прогресу інструментів для розробки, які дають можливіть прискорити ці ітерації. І вважаю, що з появою AI все буде навіть краще. Можливо зʼявляться нові мови, більш високого рівня, ніж ми можемо собі зараз уявити. Так само, як я не уявляв собі в школі, шо замість ручної реалізації сортування можна просто написати list.sort()

Але остання теза – це тема для окремого посту. А цей закінчиться тут. Напишіть, шо думаєте про це все )

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

Тим не менш, вирішив не видаляти, бо вийшло смішно. Мабуть він навіть набере більше лайків, ніж усі серйозні зазвичай. Насправді там мало бути ось це:

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

Я завжди займав перші місця на області, але на всеукраїнських не вистачало підготовки. Памʼятаю, як одну тупу задачу вирішив простим перебором відповідей до якогось великого числа. Натомість у тестовому датасети були більші числа і вона падала з index out of range. Для перевірки запускали exe, код не дивились, але якщо прога падала, то в результаті отримувала нуль балів.

Задача була така "є exe файл, на вход отримує число, на вихід дає теж число. Зробіть програму, яка робить так само". Бляха, тут просто задача на якесь логічне мислення. В результаті виявилось, що та прога просто повертала кількість цифр в числі, які мають замкнуті кола. типа 18 -> 2, 11 -> 0, 4 -> 1. Як на мене це крінж.

Цікаво, що за пару років, коли я вже був в універі, то малий зі школи зайняв якесь призове місце на всеукраїнській олімпіаді. І розказував, шо була схожа задача, де він не розібрався, і теж захардкодив. Але на відміну від мене, якщо вхідні значення не попадали під відомий словник результатів, він просто повертав рандомне значення ) І цього вистачило, аби набрати балів на призове місце. Ну, бо прога не падала, і отримала хоч щось в результаті.

А ви приймали участь в олімпіадах?

Хотів написати пост вихідного дня

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

Чергова вразливість у лінуксі. Цього разу в сервісі cups-browsed. CUPS це підсистема для друку у лінуксах (мабуть шось типу диспетчер друку у windows, але це неточно), і це її сервіс, який автоматично знаходить у мережі доступні принтери. Дуже цікаво, що в лінуксі є такий компонент який САМ ломиться в світ ще до того, як користувач це йому дозволить або взагалі помітить.

І в цьому компоненті є вразливість, яка дозволяє remote code execution. Вектор атаки – UDP запит на певний порт (631 якщо цікаво), тобто тупо зовні можна забаранити тачку.

Порада – знести нафіг CUPS / або хочаб цей сервіс чи зафайрволити його.

В твітері пишуть, шо це не дуже серйьозна вразливість, бо всі давно змирились з тим, шо друкувати з лінукса це все одно біль і сльози (це прикол якщо шо).

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

Деталі можете почитати в https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/, там багато цікавого.

Якщо ви використовуєте 2FA для захисту своїх акаунтів, і побоюєтесь атаки через SIM клонування чи перевипуск у оператора (назвіть останні 3 номери на які телефонували), то можете не переживати.

Насправді зараз можна отримати повний доступ до номеру, отримувати дзвінки і SMS без цих всіх зайвих рухів. Фактично достатньо лише знати номер жертви і мати доступ до закритої всесвітньої мережі під назвою SS7, якою користуються усі телефонні провайдери світу. А доступ такий можна отримати за якихось декілька тисяч доларів.

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

Про це розповідають у відео, посилання на яке внизу. І я б сказав, шо це якийсь пранк, якби не автори цього відео. Це колаба між двома доволі великими і поважними каналами.

Але шо я вам тут розказую, подивіться самі https://www.youtube.com/watch?v=wVyu7NB7W6Y

стрім в ефірі.
Є на ютубі: https://www.youtube.com/watch?v=tFo31VDn1xs
твітер: https://x.com/i/broadcasts/1nAKEpbNWLYxL
твіч: https://www.twitch.tv/skalinets

Доповнення: в додаток до всього написаного нижче, виявилось, що усі шпалери просто лежать на Google cloud у вільному доступі. В коментах деталі

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

А тут він запустив свою апку для ШПАЛЕР. І отримав купу негативного фідбеку. Забагато реклами, усе дорого, навіть з підпискою бачиш рекламу, і взагалі дуже багато запитів на персональні дані, як для апки зі шпалерами.

Почали зʼявлятись меми і пропозиції для творців продуктів жертв його оглядів зробити натомість огляд на його одоробло. А йому самому замість продуктів робити огляди лише на шпалери.

Також завдяки цьому пішов хайп по ключовим словам про шпалери і інші продукти несподівано отримали трохи трафіку.

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

Таке ось буває, коли переходиш на іншу сторону, і недопрацьовуєш продуктову частину. Ламати – не будувати, а критикувати – не робити.

Така от мудрість.

🚨 Думаю сьогодні зробити стрімчик. Фінальний (сподіваюсь) випуск 🚀 стартапу за 2 години.

Навалимо стилю, трошки підшаманимо і го ту прод. Усе в прямому ефірі.

Точно буде на твічі. Якщо за день налаштую інші платформи, то і на них теж (ютуб, твітер).

Приходьте о ⏰ 19:30 (приблизно, точний час напишу окремим повідомленням нижче).

#реклама курсу про highload від партнерів

⚙️ Як правильно масштабувати архітектуру, зберігаючи стабільну роботу та продуктивність при пікових навантаженнях?

Досвідом ділиться Олег Муравський, Principal Data Architect в eBay, на курсі Архітектура високих навантажень. Ви опануєте сучасні підходи для роботи з highload-системами та отримаєте фідбек інженера, який 20+ років у розробці ПЗ
⠀
❯ У програмі — best practices роботи з Big Data та огляд інструментів аналітики, обробки потоків даних, моніторингу та логування, які потрібні для розробки високопродуктивних систем

За 16 занять ви:

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

+ створите систему, здатну витримати щоденний трафік в ≥ 1 млн користувачів та масштабуватися

📚 PDF-гайд

Старт: 12 листопада

Детальніше про курс 🔗

Цікава (або жахлива, дивлячись на якій ви стороні) історія про відкрите API індійського стартапа. Стартап дозволяє робити замовлення в ресторанах і кафе (шось типу монобізу) через QR код. А його відкритість полягає у повній відсутності auth.

Ви мабуть чули жарт, що auth це зручне слово, яке означає чи то authentication чи authorization, але ти не можеш згадати у чому різниця. У випадку цього стартапу і не потрібна ніяка різниця, бо там нема ні того ні іншого. Усе доступне всім.

Хочеш усі поточні замовлення у будь-якому ресторані? Ось ендпоінт.

Чи може історію замовлень людини по її номеру телефону? Нема питань.

Статистику по ресторанам? We got you covered.

А може зробити замовлення на іншу людину / столик? Звісно, без проблем.

Ще вчора писали, що апі все ще доступне (я не перевіряв, але інфа взята з інтернету, тому це точно правда). Більше того, незрозуміло, як виправити цю проблему. Адже це breaking change, якщо додадуть auth, то зламаються усі точки доступу. А їх доволі багато.

Стартап по слухам підняв $100M інвестицій. Цікаво, шо з ним буде далі ) Зараз буквально будь-хто в твітері може навалити фейкових запитів, і фактично покласти це все.

Як казав один відомий діяч (довжина назви посади якого дозволяє дати йому позивний Дейнеріс), роль кібербезпеки перебільшена.

Оригінальний пост про цю проблему видалено, але веб архів усе памʼятає

https://web.archive.org/web/20240923081639/https://peabee.substack.com/p/whats-inside-the-qr-code-menu-at

#реклама курсу від моїх добрих друзів

🔥Fwdays Academy анонсує практичний курс з мікросервісної архітектури!

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

🕖Коли? 10 жовтня - 21 листопада
👉Реєстрація та деталі: https://bit.ly/4eyEOuB
Кількість місць обмежена.

Після проходження курсу, ви зможете самостійно:
🔸Декомпозувати систему на мікросервіси, відштовхуючись від предметних областей. Ви розглянете DDD і Event Storming.
🔸Вбудовувати мікросервіси в оргструктуру компанії.
🔸Переходити від монолітної системи до мікросервісної.
🔸Застосовувати патерни міжсервісної взаємодії та публікації API.
🔸Впроваджувати патерни тестування та розгортання мікросервісів.

🗣Ментор: Кирило Мельничук, CTO в Uspacy та AlterEGO, 18 років у web-розробці. Керує розробкою в українському стартапі Uspacy, де все побудовано на мікросервісах.

Код для підписників на дісконт в 15%: ma_micro

Отримуйте нові знання з Fwdays Academy!

Вкрав з твітору:

C – це латина. Коріння всіх сучасних мов. Колись цілий всесвіт розмовляв цією мовою.

С++ - це французька. Це як латина але з прикольними правилами. Її використовує світова еліта у вузьких колах.

JavaScript - це англійська. Кожен говорить нею, але більшість носіїв володіє нею погано і навіть не намагається вивчити іншу мову.

Java - це німецька. Вона дуже виразна та занадто складна і змусила мене плакати кілька разів. Пояснювати не буду.

Python - це есперанто. Він був створений бути таким простим, щоб хто завгодно міг його використовувати. Його носіям також не завадить час від часу ходити в душ.

Rust - це російська. Більшість носіїв мають лівацькі погляди та хочуть розповсюдити його по всьому світу.

Ассемблер - це наскальні малюнки. Всі знають про них, але ніхто не вміє їх читати. Робити їх важко.

.NET - це голандська. Як німецька, але виглядає тупо.

PHP - це португальська. Широко використовується, але мало хто її зараз вчить.

Ruby - це ісландська. Унікальна та елегантна з природнім та виразним синтаксисом, але не популярна за межами свого кола.

LISP - це іврит. Простий набір правил який використовував ще Творець Всесвіту.

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

Haskell - це баскська. Стара, елегантна, з малою спільнотою носіїв, не схожа на жодну іншу мову.

OCaml - це українська. Має відносно малу спільноту носіїв. Носії Rust вважають себе старшим братом, проте забувають якою мовою було написано перший інтерпретатор Rust.

Pascal - це давньогрецька. Ніхто не використовує її, ніхто не розуміє її, але в деяких школах її всеж таки вчать з загальноосвітницькими цілями.