Треба було видалити over 1 000 000 файлів в директорії, видалив через команду find + args, але помилився терміналом і то був сервер з БД плюс саме директорія з базою даних))
В нас був додаток месенджер, який працював на акторах (Akka) в кластері (Akka Cluster Sharding), який складався з декількох нод розподілених по двум датацентрам. Один датацентр розташовувся по один бік річки, а другий по інший бік. Так от якось у місті стався блекаут по лівий берег (знайма історія, правда?), один з датацентрів на якусь хвилину вийшов з ладу і втратив звʼязок, через це в нашому актор кластері стався сплітбрейн, датацентр на лівому березі продовжив роботу, але не мав зʼєднання більше з іншим датацентром. Найжахливіше у цій ситуації було те, що крім кластер шардінгу система акторів також використовувала akka persistence для реалізації Event Sourcing. Не вдаючись в деталі того, як це працювало, скажу, що ноди з двох кластерів, які сформувалися після сплітбрейну, почали писати в event store (базу даних для зберігання подій) паралельно, таким чином спотворюючи данні в бд, роблячі данні в ній corrupted. Нащастя, проблема була виявлена швидко, і продакшн інженери змогли вимкнути один із кластерів, а данні в бд були мануально ревертнуті до валідного стану.
В мене була ситуація коли тільки почав працювати розробником і десь через 3-4 місяці мені доручили розробляти нову фічу (до того максимум баги фіксив). Цей функціонал я розробляв трохи довго, десь 2-3 тижні (ага,саме так). От уже після успішного рев'ю і деплою на develop середовище я пішов на кухню пообідати. Під час обіду підходить до мене сіньйор розробник з проекту і каже: - Після мерджу твого коду develop середовище не працює і заблокана робота для всіх dev, QA яким зараз потрібне середовище - Зараз іду підфіксаю, там просто багато коду, але це все можна ревертнути - Та можеш уже не спішити, насолоджуйся обідом, бо це можливо твій останній обід в компанії Після цих слів сказати що у мене був шок - це нічого не сказати) Звичайно що я швидко закінчив обід і пішов шукати в чому проблема, і як виявилось хтось погано змерджився з моїми змінами і усе впало) Усе це швидко пофіксилось, але жарт про останній обід в компанії таки запам’ятався і був дуже неочікуваним)
гарний випуск, корисний. захотілось почитати, томуууу найнеочікуваніше падіння системи (працюю дата інженером) було в червні цього року, після якого був витік даних і система не була доступна клієнтам 3 дні. я не спав взагалі ці 3 дні, після чого 1,5 місяці розгрібали цей інцидент. більше деталей розповісти на жаль не можу. за короткий проміжок часу я стііііііки навчився, що весь попередній досвід здався квіточками як результат - деплою тепер в прод і руки уже не трясуться (система була написана в 2004 році)
Буда в нас база 1С, я на той час був початковим розробником, десь з рік я працював з цією базою, але багатьох єлементів не знав. Так ось, створив свою зовнішню аппку яка повинна була відредагувати данні примусово, не за логікою. Зайшовши в директорію з усіма аппками, я зплутав і відкрив не ту. В результаті чого в мене відрубився розрахунок в бд таблиць, на основі яких формується вся аналітика, та підрахунок залишків. В цій базі працювало десь 50 людей офісу, та 20 людей з виробництва. Вся робота зупиняється, і я замість того щоб просто увімкнути тригери (я на той момент не знав як їх включити), я кажу системним адміністраторам що потрібно витягувати з бекапу. В результаті чого: пів дня роботи заводу втрачено, а для відновлення всіх данних ще 4 дні проводили інвентаризацію (бо втратились штрихкоди)))))
Дякую за випуск, гарний формат. Дозволю собі не погодитись із деякими тезами з випуску. Це книга пояснює фундаментальні принципи зберігання і обробки даних, включаючи принципи розподілених систем. Це як підручник “Основи вищої математики” чи “Основи електротехніки”, але у світі комп'ютерної інженерії. Особливість цієї книги в тому, що всі принципи підкріплені практичними прикладами як це реалізовано в тій чи іншій конкретній системі. Тож книга не намагається вам продати Kafka або якусь іншу технологію. Kafka просто як яскравий приклад розподіленої streaming платформи. Теза про надійність заліза чи мережі кардинально неправильна. Починаючи з 2 розділу, книга пояснує проблеми розподілених систем, і ніякий софт (ані ваш, ані вже написаний) не вирішить ці проблеми. Тому книга пояснує які існують trade-offs при прийняті того чи іншого рішення. Ігноруючи проблеми мережі/заліза, неможливо написати надійну систему. Також книга не дасть вам відповіді як вам краще вирішити ту чи іншу конкретну задачу, але дасть розуміння на що варто звертати увагу під час вибору технології для вашої задачі. Особисто для мене, ця книга це топ 1 для всіх, хто займається проєктуванням та розробкою хоч якихось більш-менш нетривіальних рішень. У підтвердження моїх слів ви можете переглянути рейтинг цієї книги на Amazon. Я сумніваюсь, що ви знайдете ще одну “технічну” книгу з настільки позитивними відгуками.
Класний розбір книги, одразу видно хто з чим працював. ІМХО трохи забагато критики, якби я вже не читав її, то після вашого відгуку, мабуть, і не почав би. Мало говорили про те чому варто її читати і чим вона корисна. Насправді, книга дуже крута тим, що не тільки систематизує знання, а й дає базу, розуміння, як все працює під капотом і широке бачення в виборі інструментів для побудови архітектури базуючись не на хайпі, а розуміючи як та чи інша технологія працює всередині. Особисто рекомендую всім Senior інженерам прочитати її при нагоді.
Ніхрена собі "поверхнева книга"). Я би охарактеризував би книгу як сукупність концепцій, ідей, проблем і підходів, які використовуються в базах, в різних архітектурах та системах
Для мене це біблія бекендщика і однозначно одна з найращих книжок десятиліття. Такої кількості посилань на статті та інші матеріали у книжці я бачив тільки у Кормена або інших більш академічних книжках. З книжками в IT є така проблема що вони дуже швидко втрачають вартість якщо написані про якусь конретну технологію. А книжок котрі "не старіють" і водночас "вправляють мізки" дуже мало. І для мене "кабанчик" одна з таких. Автор дуже добре підібрав баланс між академічністю і популяризаторським стилем книги. І англійською читається дуже легко, що є дуже важливим в книзі якою можна когось випадково вбити. P.S. Почав читати електронну версію, але не стримався і купив оригінальну паперову версію на розпродажі амазон.
Працюю в ІТ вже більше 9 років не в Україні. Такої критики щодо цієї книги не чув ще не від кого 😅 В кожному разі, дякую за україномовний контент, друзі!🫶🏻
"SSD може посипатися - це коли останній раз було?" - кожен божий день в компаніях типу FAANG? Так, далеко не всі працюють в FAANG, але ж книжка позиціонується для тих, хто там хоче працювати
Книгу яку потрібно було заставляти читати всіх архітектів в ентерпрайзі з моменту її появи. Нажаль мав нещастя працювати з лєгасі EOL/EOS системами побудованих на SQL DB/ OLAP які в продакшені вже 12-15 років і вартість їх ре-архітекту досягає 20-30x від початкової вартості за яку їх купили і зінтегрували.І це при тому що все воно працює вже на максимально доступному зараз у світі залізі і яке для уникнення недостатку ресурсів постійно апгрейдиться
