Стендап Сьогодні

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

08.09.2022

Оповіщення AWS СloudWatch для сервісів ECS

🌡️🎛️⚠️ Продовжив сьогодні налаштовувати оповіщення Cloudwatch. Облаштував сервіси ECS (тобто, аплікації.)

Два оповіщення тривіальні — на високий рівень утилізації процесора та памʼяті. Ці дві метрики повідомляє сам ECS.

- Памʼять — на 80%. Сервіси на Ruby дуже полюбляють памʼять, але 20% треба тримати в резерві.
- Процесор — на 50%. Якщо у вебсервісу постійне навантаження до 50%, скоріш за все щось відбувається не так. Зазвичай більшість часу вебсервіси чекають або на базу, або на клієнта, тобто процесор простоює.

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

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

Друга підступніша — це вихід за нестачею памʼяті. Можна жити та не помічати, як вони трапляються. (Я знаю, бо так і було.)

Отже, хитрим поєднанням AWS EventBridge, Cloudwatch Logs, Log Metric Filter, та потім власне Metric Alarm, можна зробити так, щоб події зупинки задач ECS потрапляли до журналу, фільтрувалися за причиною (бо є ще очікувані зупинки) та підраховувались метрикою.

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

07.09.2022

День хотфіксів

🔥🧑‍🚒🚨 Сьогодні в нас день хотфіксів, може п'ять разів випускали. (То добре, що процес деплою на це готовий.)

Пара постмортем висновків.

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

- Автоматичні тривоги — це критична частина інфраструктури. А саме: в ситуації, коли у вас ламається сервіс, а ви це помічаєте вручну через години (або хвилини), або вам повідомляють користувачі, треба попіклуватись і додати тривогу, щоб наступного разу про поламку було відомо одразу. Ось, сьогодні додав тривогу на довжину черги повторів у Sidekiq. Ще шукаю можливість зробити тривогу на високу кількість перезапусків задач в ECS.

06.09.2022

Чому варто занести свої DNS-записи до Terraform

🔍🗺️🕸️ Сьогодні пораджу як зручно керувати DNS записами. А саме, варто записати їх у Terraform. Terraform - не тільки для того, щоб керувати інфраструктурою AWS; він також дозволяє описати практично будь-які налаштування, за наявності відповідного провайдера. (Провайдер — це плагін, що дозволяє Terraform робити зміни в деякому сервісі.)

Зазвичай реєстратори DNS (Godaddy, Namecheap, та інше) мають вкрай незручний інтерфейс. Особливо якщо у вас декілька доменів, то керувати всіма записами вручну це страждання. Добре що зазвичай ці записи налаштовують один раз та далі вільні про них забути; погано, що такий важливий аспект продукту так важко роздивитись.

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

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

05.09.2022

MonkeySort - цікавий інструмент для сортувавання за вподобаннями

🧹🕸️🐒 Сьогодні раптово згадав та освіжив один зі своїх стародавніх проєктів - MonkeySort. Тобто точніше, згадав один з користувачів (виявляється, такі є!) А проєкт за десять років перестав працювати через більш суворі вимоги браузерів до CDN. Треба було змінити посилання на HTTPS, але замість того я всі залежності додав до самого проєкту. До речі, великий плюс до стабільності Google та Cloudflare CDN, що вони все ще працюють. На таке можна покластися.

Що, власне, за проєкт? Про це є стаття, а якщо у двох реченнях, то це експеримент по сортуванню предметів, у якому порядок визначає людина, що порівнює їх попарно. Наприклад, так можна відсортувати задачі за складністю, або улюблені страви. Головна ідея в тому, що багато речей складно порівняти, а дві речі — легко.

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

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

- Річ на 1 бал відразу викидається.
- Речі з 2 балами теж викидаються без розбору, але не миттєво, а після закінчення оцінок (так вже легше це прийняти).
- Якщо після цього все ще залишається багато речей, то речі на 3 бали знов сортуються таким же ж чином, але вже проміж собою.
- Речі на 4 бали — це те, що майже напевно хочеться залишити, їх і не чіпаємо.
- І, нарешті, 5 балів — це стовідсотково цінна річ.

Звісно, оцінювати треба швидко, покладаючись на інтуїцію.

04.09.2022

Як я читаю новини за допомогою RSS-фільтрів

🤖🏗️🗞️ Минулої неділі я згадав, що збираю та читаю контент здебільшого через систему RSS. Сьогодні розкажу, що я роблю, коли джерело RSS не підтримує.

Річ у тім, що нічого магічного в RSS немає. Навпаки, це дуже простий формат (тому й не прижився). RSS - це просто файл ("стрічка") з переліком записів, де у кожної є унікальний URL, а також текст, заголовок, та деякі метадані. Все, що роблять програми для читання RSS - це періодично завантажують RSS-стрічки, та зберігають всі наявні записи. Потім, завдяки унікальності, вдається відстежувати статус прочитання кожного запису.

Головна перевага формату RSS, порівняно з HTML-сайтами, до яких всі звикли — це те, що стрічка чітко поділена на унікально визначені записи. Головна вада RSS - він не надає власникам контенту ніяких можливостей аналітики та мінімальні можливості оздоблення. Отже, цілком зрозуміло, що багато сайтів RSS не підтримують (Twitter), або підтримують з мінімальним функціоналом (Reddit.)

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

Нерідко навіть програмувати не треба, бо є багато готових рішень — як у хмарі, так і self-hosted. Self-hosted має ту перевагу, що легше обходить блокування (наприклад, з Instagram це критично.) В мене налаштований генератор стрічок RSSHub. Ще є декілька самописних скриптів на Ruby.

03.09.2022

Огляд програм для написання текстів: LanguageTool, Lingvanex

🇺🇦🌐🇺🇸 Сьогодні покращував свої знаряддя для написання текстів

Перше: зручна обиралка емодзі. Шукав рішення, що не буде слухати введення з клавіатури (як це робить добра утиліта Rocket.) Знайшов скрипт alfred-emoji для Альфреда. Так вдалося уникнути додавання ще одної сервісної програми. До речі, на скрипти Альфреда можна призначати гарячі клавіші, що мега зручно. Тепер в мене Hyper+: викликає меню сніпетів, а Hyper+' (сусідня) викликає емодзі.

Друге: добра перевірялка українського правопису. Для англійської мови є Grammarly (яку зробили українці, до речі.) А що для української? Знайшов цікавий проєкт LanguageTool - це практично Grammarly, але з відкритим кодом, і з підтримкою аж 16 мов. LanguageTool можна запускати локально, але в них також є платна хмарна версія що дає більш просунуті стилістичні поради для англійської. Ще саме зараз у них 50% знижка для України.

Третє: перекладач, переважно такий що працює офлайн. Я користуюсь перекладачем, щоб перевірити свої знання або розуміння деяких слів. Набрів на сервіс Lingvanex. Він перекладає більш ніж 100 мов за допомогою машинного навчання. За моїм тестуванням, працює не гірше Google Translate, але платна версія вміє офлайн. Тут поки не знаю — схоже що перекладає він добре, але маркетинг досить брудний. Почекаю наступного великого розпродажу. 🤑

02.09.2022

Роблю термінал VS Code більш зручним

🪓📺🌈 Сьогодні трошки точив сокиру. А саме: вийшла нова версія Visual Studio Code. У ній з’явилася офіційна інтеграція с термінальною оболонкою Fish. (Цією оболонкою я вже багато років користуюсь, а терміналом виключно через VSCode - може з рік.)

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

~/w/proj master ❱
echo “пише тут"

Поки розбирався, що з цим робити, та випробував різні популярні підказки, зрозумів щось інше:

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

Але підказка за замовчуванням зовсім довга та незручна:

user@Laptop.local /Users/user/work/proj > echo “пише тут"

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

🏠 ❯ echo "у корені робочого простору"
🏠 /src ❯ echo "якщо перейти в під-папку"
🌍 ~/Downloads ❯ echo "якщо вийти за межі простору"

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

(До речі, проблема з переносом була через наявний, але порожній файл fish_right_prompt.fish. Але моя підказка працює і так.)

01.09.2022

Щоб уникнути зомбування, треба навчитись думати за себе

📺🧙🧠 Сьогодні подивися відео про технології "зомбування" людей, тобто введення в оману. Головна думка: більшість людей схильні до прийняття правильно нав'язаної їм точки зору, аж до відкидання здорового глузду. Про це свідчить відомий і багато повторюваний експеримент Аша. Цим користується пропаганда на телебаченні та інше. На всяку людину можна знайти прийом, але краще всіх супротивляються ті, хто толерантні до своїх або чужих помилок.

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

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

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

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

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

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

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

Про розходження точки зору раджу подивитись стрічку "Рашьомон" Акіри Куросави.

31.08.2022

Відлагодження проблем з навантаження за допомогою AWS CloudWatch

📃🔍🐞 Сьогодні довелося шукати причину перенавантаження бази по логах в AWS Cloudwatch (це амазонівський сервіс логування та спостереження).

- З'ясували, що база почала перенавантажуватись раптово, з деякого часу. (Це просто по метриках.)
- Визначаємо - чи це база досягнула технічної межі, або чи маємо аномальне навантаження. Пишемо простий запит в Log Insights, та по гістограмі бачимо, що кількість запитів дійсно зросла стрибком. (Це можна теж подивитись по метриках.)
- Ставимо гіпотезу - додаткові запити походять з конкретного акаунту користувача (це найпростіше пояснення.) Як визначити, з якого?
- В Cloudwatch можна тегувати записи, просто передаючи в тілі записа JSON об'єкт. Але на жаль, ми ще тегували акаунтом. (Тепер будемо)
- Якщо тегів немає, Cloudwatch також вміє парсити записи регулярками, на льоту, командою parse. Це спрацювало.
- Потім за допомогою статистичного запиту stats() та сортування знаходимо акаунт з найбільшою кількістю запитів.
- Акаунт знайшли, далі вже інша історія.

PS
- Треба знати, що в Cloudwatch потік - належить конкретному процесу, а група - збирає потоки однакової форми. Наприклад, по групі на сервіс. Групувати потоки різної форми - це ускладнювати собі життя.
- До речі, навіть API Cloudwatch так побудований, що в потік можна писати тільки знаючи токен з попереднього запису, тобто виключно послідовно.

30.08.2022

AWS Parameter Store - сервіс для зберігання налаштувань і секретів

🛠️📦☁️ Сьогодні повідаю про мало відомий, але дуже корисний сервіс AWS Parameter Store. Якщо ви мешкаєте у AWS-і, то це найзручніший спосіб зберігати налаштування та секрети до вашого коду. Ось кілька фактів про нього:

- У технічному сенсі Parameter Store це key-value база даних, у якій дані - це рядки, а ключі організовані у ієрархію на кшталт файлової системи (або кращий приклад - S3).
- Для рядків до 4 КБ він абсолютно безкоштовний. Рядки від 4 КБ до 8 КБ трошки коштують (у нас з таких тільки TLS-сертифікати.) 8 КБ - це максімум.
- Керування доступом здійснюється засобами IAM та спирається на ієрархію. Тобто, можна надати доступ до якогось під-дерева. Саме так ми й робимо - у кожного сервісу свій префікс до свого дерева конфігурації.
- Окрім обмеження доступу, дані також можна шифрувати ключами KMS, що ми робимо для всіляких секретів.
- Само собою, параметри можна створювати за допомогою Terraform, як ми й робимо для параметрів, що походять з інфраструктури та "склеюють" сервіси, наприклад, їхніх адрес.
- Звісно, параметри можна отримати через API, але ще AWS ECS може передавати їх у змінні оточення (зручно це чи ні - залежить від обставин проєкту.).
- AWS веде облік версій параметрів, з датою та автором зміни. Інколи це дуже корисно.

Ми Parameter Strore широко використовуємо, тому наші rubygem та go package вміють завантажувати параметри у вкладену структуру JSON. Тож і вам раджу.

Раніше

Пізніше