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

Ще коли бути айтішніком не було модно, опції віддаленої роботи не існувало, і не було скраму та айфонів, одна компанія сформулювала важливі для неї принципи (чи цінності). Їх було 37 (один з них пояснює, чому саме таке число). Ну і сама компанія теж називалась 37 signals. Це була перша з компаній (про які я чув), яка заохочувала віддалену роботу, навіть написали про це книжку Remote. Власне, це не єдина їхня книжка, були ще, і це була доволі потужна література на той час (та й зараз можна почитати).
Зараз ця компанія відома, як Basecamp. А ще саме вони придумали Ruby on Rails.

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

Ось, власне, і посилання: 37signals.com

Напишіть в коментах, що вам з цього заходить.

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

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

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

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

Насправді можна. В кубернетесовському репо kubernetes/autoscaler є проект Vertical Pod Autoscaler, який як вміє рекомендувати правильні налаштування ріквестів і лімітів з огляду на фактичне споживання. Крім того, він може сам їх змінювати, використовуючи різні стратегії.

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

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

Це чудовий варіант порізати всі свої сервіси, потім поспостерігати за їх поведінкою

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

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

Таким трафіком може бути стягування імеджів з ECR репозиторієв, читання S3 бакетів через private link і навіть простий доступ до сервісу в кубернетес.

Ось корисна стаття про вартість передачі даних для різних сценаріїв використання контейнерів у AWS.

Про кібер атаки нема що особливо писати, після першого місяця війни я до них доволі скептично відношусь. Ті інструменти, що я бачив, не схожі на щось доволі ефективне. Так, вони можуть завалити незахищений сайт, проте будь-який хоч трохи підготовлений адмін може поставити захист від  DDoS і звести ефективніть умовного бомбардера до нуля. Десь чуваки пропонують ставити собі на компи свій софт (а перед тим вимкнути антивірус) – таке собі задоволення якщо чесно. Схоже на масову (вже не таку масову, але все ж) істерію без якогось помітного фідбеку. В каналах публікують якісь скріни, що показують, що умовний сайт лежить. У айтіармії є навіть дашборд на сайті, де теж багато чого "лежить", але насправді я взяв перший ліпший ресурс і... гляньте в коменти, там буде скріншот 🙂

Для повноцінного зламу систем потрібен фах і досвід. Я переглянув декілька курсів по ethical hacking і там суцільна банальщина. Так, розказують про різні методики атак, проте вони працюють лише на дуже незахищених (часто спеціально підготовлених) цілях. Я не знаю, де може спрацювати sql injection, наприклад 🙂 Будь-який сучасний фреймворк чи плагін використовує параметри. Можливо є такі цілі, особливо у внутрішніх системах, бекофісах і тд, але для їх атаки треба зайти за периметр, що зазвичай не так вже і просто. Таке не опановується за місяць, потрібна практика і ментори і відповідні групи. В які просто так з відкритих каналів попасти неможливо (принаймні має бути).

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

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

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

Канал з 300К підписниками від творців "держави у смартфоні" запустив бота, якому пропонують скидати рутові паролі від своїх ресурсів. Це потрібно начебто для синхронизації атак на русню. Але... це виглядає максимально тупо. Ще й чуваки схему виклали (ось тут у нас mysql, там всі паролі).

Чи може я помиляюсь і це все геніальний задум? Напишіть в коментах, мені дійсно це цікаво 🙂

Ось опис бота: https://itarmy.com.ua/bot/

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

Це я до чого. Якщо ви знаєте якісь більш менш організовані групи чи спільноти, будь-ласка поділіться у коментах, або особистих повідомленнях.

А тим часом ось вам непогана стаття про атаки та (що важливо) інструменти: https://pentest.blog/how-to-perform-ddos-test-as-a-pentester/

Не думав колись, що буду форвардити повідомлення від Мінцифри, але часи змінились

Це інфа з нашого корпоративного каналу з безпеки, було декілька звернень про такі випадки.

Вам могут звонить и писать, представляться сотрудником Телеграма и Вайбера, а также просить назвать код который придет в СМС или через мессенджер. НИКОГДА не называйте код НИКОМУ!
Если такой код к вам приходит без вашей иницииации - скорее всего Ваш Телеграм уже пытаются увести.

https://www.youtube.com/channel/UCSQSxUJb4zH1SEpzNerSLLg/about треба забанити

сайти-таргети для ддос зі статусом
http://www.mordor-sites-status.info/about
https://incourse.trade/sites.php

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

Декілька важливих фактів про ці месенджери:
Вони працюють за рахунок Bluetooth, тобто на відстань до 50-100 метрів.
Використовують нікнейми вашого пристрою для відображення у месенджері, наприклад, “Паляниця iPhone”.
Не отримують доступ до контактів пристрою, а будують спілкування з пристроями, що знаходяться поруч.

iOS

Berkanan - безкоштовний
Поки що найкращий офлайн-месенджер для iOS, можна як слати повідомлення, так і дзвонити.
https://apps.apple.com/ua/app/berkanan-messenger/id1289061820?l=uk

Vojer - $24
Платний, але за таку ціну є круті фішки, крім пересилки тексту ще можна пересилати фото та голосові повідомлення.
https://apps.apple.com/ua/app/vojer-be-connected-conference-or-in-roaming-be-intouch/id913585553?l=uk

Android

Bridgetfly (на iOS коректно не працює) - безкоштовний
Дозволяє відправляти повідомлення як в загальнодоступний канал (будуть бачити всі пристрої, у яких встановлено додаток, та які знаходяться в радіусі покриття bluetooth сигналу), так і окремим користувачам.
https://play.google.com/store/apps/details?id=me.bridgefy.main

Briar - безкоштовний
Дозволяє відправляти повідомлення та картинки без використання мережі Інтернет.
З недоліків - потрібно заздалегідь поділитись QR-кодами, чи лінками, щоб додати новий контакт
https://play.google.com/store/apps/details?id=org.briarproject.briar.android

Всі апки налаштовуються інтуїтивно, тому додаткових інструкцій не вимагають!
Встановлюйте вже зараз і тестуйте, щоб бути напоготові!
Слава Україні! 🇺🇦

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

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

Власне, ось пост https://dou.ua/forums/topic/36592/

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

Проте по тому посиланню є набагато більше всього – крім інфографіки, там підбірка чумових тредів на теми архітектури, AWS та клаудів. Ну і звісно та сама інфографіка (наприклад, шпора по сертифікації AWS Solutions Architect Associatee). Але що тут писати – гляньте самі.

Той самий твіт про DynamoDB: https://twitter.com/tpschmidt_/status/1493958661391233026

Треди: https://tpschmidt.com/#threads

Колись давно читав книжку "Production-Ready Microservices", і це був перший раз, де я побачив термін SRE. Дуже цікава і корисна книжка, яку я звісно всім рекомендую, якщо у вас є продакшен і мікросервіси. В її кінці є список того, що має бути зроблено і враховано під час розробки тих самих мікросервісів. Деяки пункти можуть здаватись очевидними, а деякі викликають реакцію "точно, як же я до цього не додумався". В купі це доволі солідний фундамент для побудови якісного процесу розробки і експлуатації сервісів без зайвого гемору.

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

Я навіть взяв його, скопіпастив і виклав на github (з ознайомлювальною метою).

Книжка: https://www.amazon.com/Production-Ready-Microservices-Susan-Fowler/dp/1491965975

Чекліст: https://gist.github.com/skalinets/536295e9f0fa7bf82bfd10285a50c1ae

До речі, про System Design Interview. У минулому пості я писав, що раніше стикався з цим явищем. Свого часу я знайшов курс на educative і хочу вам сказати, що це тупо шедевр. Він не лише про інтервью. На прикладі відомих сервісів (твітер, убер, меседжер) там пояснюється і сам процесс системного дизайну, на що треба дивитись, що враховувати, і які патерни і поняття використовувати. Після перегляду можна сміливо апгрейдитись до архітектора.

Сервіс платний, проте вартий своїх грошей. Рефералки в мене немає 🙂

курс "Grokking the System Design Interview": https://www.educative.io/courses/grokking-the-system-design-interview

Пост для коментів для попередніх постів

Це мій перший канал у телеграмі, і я ще опановую усі його фішки. Наприклад, я не одразу увімкнув коментарі, на що звернули уваги пильні читачі. Пізніше коментарі зʼявились, але вони доступні лише для нових постів.

Тому і зʼявився цей пост. Саме тут можна накидати коментів до попередніх постів