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

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

Проте в розподілених системах синхронна взаємодія не дуже заохочується. Якщо сильно упаруватись в 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 - це давньогрецька. Ніхто не використовує її, ніхто не розуміє її, але в деяких школах її всеж таки вчать з загальноосвітницькими цілями.