#redis

А вот antirez, супер успешный программист, работающий над по-настоящему сложными задачами, создатель redis, одной из самых популярных баз данных на свете, делится, как он использует ИИ для программирования.

Вкратце: даёт подробный контекст и пишет детальную спецификацию, не вайбкодит и даже не пользуется специальными редакторами (агентами), а буквально копи-пестит код; рекомендует модели Gemini 2.5 PRO и Claude Opus.

Говорит, что нейросети радикально ускоряют его работу. Внутри у него еще пара советов, рекомендую прочитать первоисточник, там коротко и по делу.

Мы в iGooods лежали почти полдня. Стыдно! Зря я угорал вчера над утконосом, что они упали. Поделюсь честно, от чего мы лежали. Это подробный постмортем аварии с техническими подробностями, мама, извини.

—

Из-за коронавируса к нам начали приходить в 2-3 раза больше клиентов, чем обычно. Плюс у нас на днях запускается два новых партнерства — с Joom и с магазинами Лента. Серверы работали на 40-60 процентах емкости и мы решили «добавить железа». В 6 вечера мы налили пару новых машин в кластер приложений, в час ночи по Москве — перетащили базу на новую, ультра мощную тачку. Обе операции — необычные для iGooods, множество вещей делалось руками. Ошибка №0 — мы сделали 2 крупных изменения близко друг с другом

В 7 утра по Москве, сервер базы данных начал плавиться от нагрузки в процессор. Это компьютер с 70 ядрами, но базе нужно было минимум 300. Запросов было вроде бы не сильно больше, чем обычно, но занимали они всё больше времени. Люди просыпались у себя дома и начинали делать заказы — сервера умирали, сайт не открывался, приложения выдавали ошибки. Самое опасное — курьеры и сборщики заказов выходили на работу и не могли работать.

Мы, конечно, думали, что сможем быстро починить проблему. Через час стало понятно, что нужно хотя бы временное решение. Мы выключили все пользовательские интерфейсы iGooods, оставив рабочей только админку и внутренние приложения курьеров и пикеров (сборщиков заказов). Ошибка №1 — в случае аварии не нужно пытаться «сделать хорошо», нужно определить критичные сервисы и восстановить их первым делом.

Мы решили, что проблема в новой базе данных. Мало ли, конфигурация, железо, да хоть драйверы. Попытались вернуться на старый сервер. Мы не сохранили WAL логи между переездами, так что вместо 3 минут эта операция заняла 40 минут — пришлось перегнать всю базу данных между серверами. Мы планировали откат для приложений, но не для переноса базы — он нам казался довольно безопасной операцией. Ошибка №2 — мы решили, что «уж тут-то не взорвется», на самом деле вместе с любым изменением нужно продумывать пути отката.

Возвращение на старый сервер базы данных не помогло. Каждый раз, когда мы включали пользовательские приложения — база данных мгновенно уходила в несознанку и работа бэкофиса парализовалась. Сайт и мобильные приложения к тому моменту лежали уже больше нескольких часов. Самое страшное — мы всё ещё не были уверены, что проблема не в базе данных.

В конце концов, Женя случайно заметили ошибку, что наше rails приложение не может записать в redis-кеш. BINGO! Вот тут всё наконец-то встало на свои места. В нашем приложении есть много страниц, которые собираются очень долго. Все они кешируются rails'ами в redis. И вот этот редис кеш у нас отвалился на запись на части серверов приложений из-за кривых настроек окружения (душераздирающие подробности приложены картинкой). Кеш протухал постепенно и с каждой потерянной записью все больше тяжелых запросов грузили Postgres. Ошибки №3, 4 и 5: настройка тачек производится руками, не кодом; логи переполнены, так что сложно заметить новую ошибку; не все важные сервисы (redis, rails cache) включены в мониторинг.

Как вы можете видеть, всё довольно банально. Будь у нас настроена нормальная рабочая среда — не было бы такой аварии.

Итак, чего нам не хватило и что мы приведем в порядок:
- инфраструктура в коде (полный ansible вместо хождения руками на серверы);
- хороший, чистый мониторинг всех ключевых метрик приложения, APM — за день до аварии мы включили Datadog, но ещё не было нормальных дэшбордов и исторических данных;
- сообщения об ошибках (у нас bugsnag) засраны нерелевантными сообщеними — их нужно почистить.

Мы с Федей обозначили проблемы в первые же дни, но не успели решить их — были вещи поважнее. Знал бы прикуп — жил бы в Сочи.

Если у вас похожая ситуация — рекомендую навести порядок заранее, не ждать форс-мажора.

Ну и делать много сложных правок вместе — чревато. Стоило разнести перенос базы и деплой новых машин на день — тогда бы мы не потратили так много времени на ложный след тормозной базы.

Fin.

Ключевые разработчики SQLite — христиане. Когда несколько корпораций потребовали Code of Conduct (правила поведения в сообществе разработки), то они не долго думая переняли устав Святого Бенедикта (Ⅴ век). Участники проекта предсказывали, что это плохо кончится. Прошло полгода, новость дошла до Hacker News и особо буйные борцы за социальную справедливость уже точат вилы в твиттере.

Вспоминается, как из Drupal выгнали одного из ключевых разработчиков из-за его излишней приверженности нетрадиционным BDSM-практикам.

Другое движение, которое хочется упомянуть в связи с CoC - воинствующий отказ от терминологии master-slave (господин-раб). Это классические термины в технологиях, которые появились задолго до компьютеров, описывают отношение ведущих и ведомых сущностей. Часть американцев считает, что эти слова нужно запретить, потому что они напоминают о рабстве чёрного население соединенных штатов.

Свежий представитель этой борьбы - недавняя история с Redis. Разработчик-итальянец сначала бодро разложил борцов в мощном памфлете (рекомендую прочитать оригинал): «вместо того, чтобы насаждать свои американские правила речи остальному миру, лучше, перестаньте убивать негров». Потом ему написал DHH (супер авторитетный программист, создатель Ruby on Rails, опять же рекомендую прочитать тред в оригинале) и другие классные пацаны. В результате он решил, что поменяет термины в проекте ради сообщества (servant leader, yo), но в ответ добавил в redis команду LOLWUT, которая 1) не имеет ничего общего с базами данных 2) работает быстро (можно запускать в продакшене!) 3) показывает что-то красивое и меняется с каждым релизом. Такой вот протест.