Однажды я столкнулся с проблемой, когда почти потерял коммерчески успешный пет-проект из-за устаревших резервных копий БД (ещё до того, как он стал коммерчески неуспешным). При этом, даже после частичного восстановления, все-таки потерял ~30% прибыли от проекта, много нервов и времени.
Это подтолкнуло меня на разработку своего открытого инструмента для бекапа PostgreSQL. С разными хранилищами, уведомлениями при сбоях и health check'ом. Собственно, о том, как я потерял деньги и затем разработал проект — хочу рассказать в статье ниже.
Содержание
История, как я испортил базу и не смог до конца восстановиться
Правила по работе с БД, которые я теперь внедряю во все рабочие проекты
Про open source проект для резервных копий PostgreSQL
Я выложил в open source свой проект для мониторинга и бекапов PostgreSQL. Проект разрабатываю и использую уже более 2-х лет. Разрабатывал с ориентиром на потребности своего рабочего и "пет" проектов.
И только недавно осознал, что проект, в общем-то, помогает знакомым, имеет публично-презентабельный вид и может быть полезен для сообщества.
Стек проекта: Go, gin, gorm, React, TypeScript, PostgreSQL и всё в Docker + Docker Compose. Изначально проект был на Java, но со временем был переписан на Go.
Фактически, это UI обвязка над стандартным pg_dump. С дополнительными функциями, которые улучшают UX стандартной утилиты и добавляют интеграции с внешними сервисами для хранения бекапов и уведомлений.
Что умеет:
-
Делать резервные копии по расписанию (например, каждый день в 4 утра или каждое воскресенье в 12 ночи) для PostgreSQL с 13-й до 17-й версии.
Бекапы хранятся в сжатом виде локально на сервере, в S3 или Google Drive. В планах добавить Яндекс Диск, NS сервера и FTP.
После каждого бекапа вам отправляется уведомление, что всё хорошо (или наоборот — плохо). Уведомления об успешных бекапах опциональны.
Уведомлять в Telegram, на почту и в Slack, если БД не отвечает.
Причём уведомляет только через n неудачных попыток (чтобы нивелировать ложные срабатывания из-за сети) и показывает график доступности.
В планах добавить Discord, Mattermost и другие каналы связи.
Разумеется, проект бесплатный, открытый (под MIT лицензией), self hosted и с человеческим веб-интерфейсом.
Сайт проекта - https://postgresus.com/
GitHub - https://github.com/RostislavDugin/postgresus
P.S. если проект кажется полезным и если у вас есть аккаунт на GitHub, пожалуйста, поставьте звёздочку ⭐️. Первые звёзды тяжело собирать. Буду крайне признателен за поддержку!
UPD: утром один из хабровчан @vasyakrgзаписал обзор на проект - https://youtu.be/cYakOUyvAa8 ?.
История, как я испортил базу и не смог до конца восстановиться
В 2023-м году у меня был пет-проект, который давал доступ к ChatGPT (ещё к 3.5) в РФ без зарубежной карты и номера телефона. Обычная перепродажа доступа через API с наценкой. Проект рос, потом пошёл на спад и я его продал. БД проекта бекапилась консольной утилитой по типу PgBackRest раз в сутки на другой сервер.
Об этом у меня осталась статья 2023-го года: "Как я заработал 500 000 рублей, сделав доступ к ChatGPT. А потом Яндекс убил SEO и всё (почти) закончилось"
В момент, когда проект приносил ~$1 500 на пассиве и был в пике доходности, произошло плохое: я испортил данные в базе.
Это была пятничная ночь, я был уставший, фоново отвечал на сообщения и был максимально расфокусирован. В этот момент клиент попросил поменять почту для доступа к аккаунту.
Через SSH и psql я полез в продовую базу, ввёл запрос в духе:
UPDATE users SET email = 'customer@email.com' WHERE email ILIKE '%%'
Затем отвлёкся, чтобы посмотреть нужную почту в чате и... на автомате нажал Enter. После чего увидел что-то в духе AFFECTED ROWS: 10 000.
Это был единственный раз за много-много лет, когда у меня пробил холодный пот на спине. Буквально.
Дисклеймеры
Разумеется, я знал, что неплохо бы сначала делать SELECT, сделать SAVEPOINT и т.д. Но, как во всех таких историях, базовые правила техники безопасности были проигнорированы, что привело к фатальным последствиям.
Все пользовательские почты были затерты. И тут важное уточнение: по правилам платёжных систем, если пользователь не может получить доступ к оплаченной услуге — это грубейшее нарушение. Разумеется, больше никто не мог войти в аккаунт и уже начали сыпаться жалобы.
Я полез в бекапы — и холодный пот пробил ещё раз. Последний бекап был примерно месяц назад ?. Восстановиться из него уже нельзя. Всё это время платежи добавлялись, подписки отменялись (а значит нельзя было восстанавливать тех, кто уже не хочет платить) и т.д.
Кое-как за оставшуюся ночь и утро я смог скриптами восстановить ~65% базы по IDшникам пользователей. Остальным пришлось отменять подписки и возвращать деньги. Было больно, неприятно и дорого.
Урок был очень сильно усвоен...
Как начал разрабатывать проект
Было принято решение: разработаю себе такой инструмент для бекапов, который будет каждый день присылать уведомления, что все хорошо! И восстанавливать всё в пару кликов! И блек джек с микросервисами! И API метод для проверки жизнеспособности утилиты сделаю!
Первую версию Postgrusus'a разработал буквально за месяц на Java. Начал использовать. Иногда давать пользоваться знакомым. Дорабатывал по мере своих потребностей и по мере поступления обратной связи.
Оказалось, что удобно. Несколько раз резервные копии спасали и меня, и не только лишь меня. Название у проекта появилось только два месяца назад, до этого репозиторий назывался "pg-web-backup".
Конкретно сейчас Postgresus решает для меня следующие задачи:
Выступает главным инструментом для бекапов, если проект маленький или живёт на VPS, а не в облаке с облачной базой данных.
Выступает резервным инструментом для бекапов, если проект большой, живёт в облаке с DBaaS и с облачными резервными копиями.
Бекапит базы на "всякий случай" (если вдруг облако умрёт, заблокируется, база случайно удалится вместе с резервными копиями из-за неуплаты и т.д.). Всяко лучше иметь дубль бекапов, чем попасть в тот неудачный 0.01%, когда даже облако накрылось и нет плана Б.
Дальнейшие планы
Сейчас в планах дорабатывать проект в следующих направлениях:
Добавить больше PostgreSQL-специфичного мониторинга нагрузки (
pg_stat_activity,pg_system_stat,pg_locks), но с удобным UI.
Эдакая альтернативаpostgres_exporter+Grafana, но из коробки вместе с резервными копиями.Наблюдение и алертинг в случае замедления ключевых запросов.
У меня в рабочем проекте есть таблицы и специфические функции, которые ещё рано оптимизировать (если гипотеза провалиться — можем удалить). Но потенциально могут вырасти по данными и упасть в скорости.
Условно, если запросINSERT INTO users (...) VALUES (...)начал занимать больше 100мс, а у нас поток новых пользователей только растёт — нам прилетит уведомление и мы пойдем оптимизировать.Собирать статистику запросов по CPU time и частоте выполнения, чтобы видеть, куда уходят основные ресурсы и что стоит оптимизировать.
Добавлять больше источников для уведомлений и хранения данных.
Правила по работе с БД, которые я теперь внедряю во все рабочие проекты
Напомню две народные мудрости:
Системные администраторы делятся на тех, кто ещё не делает резервные копии и тех, кто уже делает резервные копии.
Не только делай резервные копии, а ещё и регулярно проверяй, что из них получается восстановиться.
С тех пор как я испортил БД своего проекта, я категорически без исключений принял на вооружение следующие правила:
перед любым
UPDATEвсегда делатьSELECTи проверять, что выбирается всего 1-2 строки;если изменение большое — ставить руками
SAVEPOINT;проводить "учения" по восстановлению минимум раз в 3 месяца. Причём как из облачной копии, так и из локальной. Чтобы в ответственный момент не оказалось, что данных нет, резервные копии не работают или восстанавливаются слишком долго.
За прошедшие 2 года были прецеденты, когда требовалось восстановление из бекапов — всегда получалось и в облаке, и из Postgresus'a. Проблем не было, потому что всё было отлажено на этапе тестов. Базовые правила техники безопасности работают.
Заключение
Надеюсь, мой проект окажется полезен для широкого круга разработчиков, DBA и DevOps'ов. Планирую развивать его дальше, повышая его полезность в боевых задачах. Буду рад любым предложениям и комментариям по улучшению.
Может быть интересно:
P.S. Ещё у меня есть Telegram канал, если вдруг интересны мои заметки о разработке.
Комментарии (37)
chemtech
13.07.2025 12:13Спасибо за пост. А через код можно настроить postgresus ?
RostislavDugin Автор
13.07.2025 12:13А зачем именно через код?
Вообще... нет. Я наоборот старался, чтобы не нужно было ничего делать в коде \ конфигах \ .env файлах. Чтобы всё было в UI и максимально тривиально без CLI
13werwolf13
13.07.2025 12:13А зачем именно через код?
потому что это удобно. зачем часами настраивать вручную везде одно и то же если можно поправить пару переменных в ansible inventory и задеплоить одной командой, зачем бекапить конфиги если можно их восстановить из iac одной командой, зачем кричать через весь офис "какой мудак это сделал" если можно посмотреть в истории гитовых коммитов кто и когда это сделал..
IaC это лучшее что изобрело человечество!
P.S.: это не отменяет настройку через UI. хороший софт обычно является универсальным, чтобы можно было нужные настройки и в конфиге прописать, и через env передать, и в вебморде мышкой натыкать. а идеальный софт ещё имеет возможность оставить только один из способов выключив остальные.
vasyakrg
13.07.2025 12:13конкретно в этом софте я бы иаку предпочел бы апиху. под иак скорее оператора придется писать, а их как бы уже есть на рынке и поддерживаемых целыми командами.
а вот апиху сюда бы можно было, да. конфигурить действительно есть что, когда баз не 2-3. тем более, что под капотом, судя по коду, вполне себе backend <> frontend с контроллерами и методами.
13werwolf13
13.07.2025 12:13Не понял.. Зачем оператора?
P.S.: грамотно продуманная апиха тоже может использоваться для пинания через IaC, хотя это и не труъ
Timmek
13.07.2025 12:13А как так вышло, что поле “email” не было ключом/только уникальным ?
RostislavDugin Автор
13.07.2025 12:13Не ключ и не уникальное, потому что помимо почты были другие сервисы входа. Следовательно, email мог быть много у кого NULL
PetyaUmniy
13.07.2025 12:13Делать коробки все в одном, имхо, для опенсорса это странное решение. Разумеется если это для кровавого ынтерпрайза, да еще если это проприетарь за бешеные доллары - тогда это база.
Совеременные IT продукты довольно сложные, в них и без того много сущностей, источников разных событий, метрик, алертов и т.д. Если вы будете для метрик, алертинга, рисования графиков использовать свои велоспеды, то вы будете сильно увеличивать сложность вашего продукта.Каноническим инструментов мониторинга и алертинга в современном IT является prometheus, отправщиком вебхуков - alertmanager, рисователем графиков - grafana. Почему бы не использовать их? Сколько времени можно съэкономить на отсутствии необходимости их разрабатывать и вникать в кустомные велосипеды при эксплуатации. А уж вопросы интеграции даже обсуждать нечего.
Сам типичный инстанс postgresql бекаплю 2мя независимыми путями (все деплоится и параметризуется через ansible (включая helm), все в контейнерах, частично в кубере):
PITR: wal-g для wal + shell обертка вокруг wal-g генерирующая prometheus метрики/статус для basebackup'ов + скрипт python генерирующий prometheus метрики о состоянии бекапов в хранилище (например о пропущеном сегменте или отсутствии изменений в течении периода) из вывода wal-g (да, используя exeс) + cronjob python восстанавливатеть бекапов с прогоном стандартных тестов (встроенный тест целостности и
pg_dump > /dev/null) и пушатель результата в prometheus pushgw.Архив: shell обертка вокруг restic: получение списка баз, последовательный бекап каждой базы (
pg_dump | restic backup --stdin, т.е. без сохранения промежуточного состояния на диск) в отдельный репозиторий, экспорт prometheus метрик для каждой базы. Хочу когда-нибудь прикрутить восстновление и сюда. Но беда в том что для дампов нарушается прозрачность процесса восстановления. При восстановлении нужно чтобы были созданы например роли присутствующие в дампе. Не придумал красивого решения, как это не сопровождать и чтобы оно не ломалось.
Когда соберусь менять место работы попрошу разрешения работодателя заопенсорсить (больше для самого себя, использовать в будущем, не повторять эту работу). Сейчас увы нет времени и мотивации причесывать до такого состояния чтобы было не стыдно выкладывать в паблик.
RostislavDugin Автор
13.07.2025 12:13Исходя из вашего комментария, чтобы бекапить \ мониторить БД простому бекенд разработчику уровня junior-middle нужно:
поставить где-то экспортер данных из БД;
разобраться в Prometheus, развернуть и настроить;
разобраться в Grafana, развернуть и настроить;
разобраться в alertmanager и настроить, исходя из событий Prometheus;
написать скрипты для бекапов;
Имхо, для человека, который не DevOps \ админ \ отвечает за инфру \ Senior'a - явный перебор. Каждый раз, когда я всё это разворачиваю - у меня уходит день-два + болит голова, а всё ли актуально \ не отвалится ли чего.
Ну и нужно не забывать про поддержку этого, когда разработчики в команде меняются.
А проект, который я делаю:
развернуть скриптом за 2 минуты;
добавить БД за 1 минуту;
подрубить ТГ бота за (если разобраться) 5 минут.
И готово!
Разумеется, это не подходит для серьёзного мониторинга, больших проектов и т.д. Для основного моего рабочего проекта у меня всё и настроено +- как вы описали (+ ещё метрики из облака тащу скриптами в Prometheus).
Но для большинства маленьких-средних проектов, которым достаточно мониторить БД - Postegusus'a будет с головой. А главное быстро и удобно. Но это точно не серебрянная пуля.
PetyaUmniy
13.07.2025 12:13Пожалуй я с вами соглашусь. Это имеет смысл.
Какая-то уже проф деформация, совсем не подумал что существуют проекты на 4 контнейнерах: postgres + backend + frontend + http proxy.
S0mbre
13.07.2025 12:13Большинство проектов (у меня лично) именно такие. А если они не такие, то я их разбиваю на микросервисы и делаю такими.
Joey_Nim
13.07.2025 12:13Ага, вместо готовых инструментов являющимися по факту бест практис давайте будем пилить свои собственные гвоздями прибитые решения. Что бы вы не говорили разработка всегда дороже погружения.
Будь у вашего проекта иак, свой экспортер, а вместо пгадампа можно было выбрать скажем какой-нибудь пгбэкрест - цены бы не было. Сразу из коробки и питр заработает и интегрировать легко куда угодно хоть в энтерпрайз хоть в самые мелкие пет проекты.
Погрузиться в прометеус стек это один раз написать компоуз с прокинутыми в волумы дошбордами и алертами и собственно всё
mvv-rus
13.07.2025 12:13Затем отвлёкся, чтобы посмотреть нужную почту в чате и... на автомате нажал Enter. После чего увидел что-то в духе AFFECTED ROWS: 10 000.
Я вот когда-то давно много работал с Interbase через его утилиту Windows ISQL, и меня бы такое сообщение не привело бы в отчаяние. А всё потому, что Interbase использовал многоверсионную схему хранения, и старые записи никужа не девались. А утилита транзакцию автоматически не закрывала - нужно было руками закрыть, через интерфейс.Так что, увидев нечто неожиданное (бывало и такое), я просто откатил бы транзакцию, и всё.
Это я к тому, что PostgreSQL тоже, говорят, поддерживает многоверсионную схему хранения, и если бы разрабочики утилиты для выполнения SQL задумались о том, чтобы не закрывать автоматом транзакции, вам было бы в тот момент легче.
А вообще, править данные в боевой базе через SQL - это плохая практика, примерно столь же плохая, как и не делать резервные копии.
PS А админы всё же делятся на тех, кто делает бэкап и тех, кто ещё не терял данные.
aronsky
13.07.2025 12:13Из предыдущей статьи автора:
Ну я и полез в базу, чтобы обновить SQL-скриптом одну почту. Написал сначала скрипт WHERE, чтобы проверить выбор только одной почты. Затем для такого же WHERE написал уже UPDATE скрипт. И, по всей видимости, где-то не закрыл скобку. Запустил. Через секунду все ~25 000 почт стали NULL. В момент у меня пошёл холодный пот по спине и я подвис на две минуты. Но бекапы были на месте, я восстановился и пошёл менять футболку на сухую. Оказалось, дропнуть базу на проде действительно можно.
Как будто бы та же история, а как будто и не понятно где правда.
RostislavDugin Автор
13.07.2025 12:13Спасибо, не обратил внимание
В прошлый раз я сократил путь про это восстановление, чтобы не растягивать без того долгую статью и... немного не перепроверил данные, написал "примерно" по памяти (всё-таки не самый важный момент)
Для этой статьи я полез в сообщения того дня и нашёл конкретные цифры и +- точную хронологию. 25к было в момент закрытия проекта, 10к в момент дропа базы - поправил цифру в старой статье
SabMakc
13.07.2025 12:13Именно поэтому я все подобные скрипты сначала оборачиваю в транзакцию, которую явно откатываю в конце (для "боевого" выполнения надо раскоментить строчку с коммитом транзакции).
Да и то бывают нюансы - зачастую есть возможность выполнить выделенный скрипт... И UPDATE-SET часть скрипта - вполне валидный скрипт, даже без выделения WHERE-части... Благо, что на "боевых" базах не попадался на подобный прикол...
hogstaberg
13.07.2025 12:13Да, но... pg_dump это не то чтобы про бэкапы, это скорее экспорт в sql statements, который в случае маленьких баз может служить в качестве бэкапов. Как только ваша база становится сколь-нибудь ощутимого размера и у вас появляются сколь-нибудь жёсткие требования ко времени восстановления - ну привет, бинарный бэкап и wal.
RostislavDugin Автор
13.07.2025 12:13Соглашусь, для больших баз - инструмент не подойдет.
Как минимум, пока что. В планах хочу добавить WAL
gecube
13.07.2025 12:13Насколько это актуально при использовании https://github.com/cloudnative-pg/cloudnative-pg ?
vasyakrg
13.07.2025 12:13Да почти не актуально. Там свое есть, правда сразу кластером, а не отдельной базой. А что бы отдельно и манифестами - я свое пилил - https://github.com/vasyakrg/pgdump-s3
denizkino_mesto
13.07.2025 12:13Автор, считаю тебя молодцом. Пофиг, что пишут гении далёкие от заработка денег на своих проектах и со своими людьми, перед которыми ты всегда в ответе. Я тоже попадал в передряги с резервными копиями, хотя всё вроде бы кругом работало как положено :) и подход сделать своё, что нужно всегда работал отлично и твой мне понравился с отличными интерфейсом, выглядит круто, незнаю как работает, но считаю такую штуку особенно для postgressql особенно для 1С-ников можно продавать прям на ура.
overslepter
13.07.2025 12:13Я что-то не понял, а где вариант "каждая база бэкапируется автоматически системой управления бэкапами". Что выбирать если нужного варианта нет?
ky0
Что делает бизнес, чтобы не обнаружить, что восстанавливать продовую БД нужно из месячной давности бэкапа? Нанимает админа до.
Что делает разработчик-стартапер, когда обнаруживает месячный бэкап? Пишет свою вебморду для pg_dump после :)
Ничего не могу сказать, достойный подход.
RostislavDugin Автор
Что именно вы понимаете под "бизнес"?
У меня был мелкий проект, где денег хватало на сервер, доступ к API и немного на маркетинг. Это не тот проект, где имеет смысл нанимать сис. админа. Собственно, проект для таких же
Но, как я и написал — ошибка глупая, моя личная, сам виноват. Причина не в инструменте, а в человеческом факторе :). Нужно было проверять, что бекапы делаются, аккуратнее писать запрос и проблемы не было бы
А Postgresus не для решения проблемы "бекапов" в целом, а просто маленькое улучшение UX. Чтобы на одном экране удобно добавить базы за 30 секунд без CLI, выбрать расписание и быть спокойным
ky0
Под бизнесом я имею в виду группу людей с некой идеей и желанием на ней заработать. Хорошо, когда они нанимают профессиональных управленцев, которые знают большую часть проблематичных мест, одно из которых в айти, как раз - начинать проект без предварительной подготовки инфраструктуры под него.
Для мелкого проекта админ в штате не нужен, тут с вами соглашусь - достаточно купить несколько часов опытного фрилансера.
polRk
Или просто взять managed db
xenon
Я так мониторинг (https://my.okerr.com) делал. После нескольких этапов апгрейда себя. (каждый может прочитать и поставить себе метку ">>> вы сейчас здесь <<<" на соответствующем пункте)
Не делаем бэкапы (бэкапы для трусов!). Сервер падает. Бэкапов нет. Ура, мы получили ценный жизненный опыт!
Делаем бэкапы. Падает. Ищем... о, а последний бэкап мы делали полгода назад.... Ура, левел-ап!
Делаем бэкапы скриптом. Падаем. Смотрим... а их нету. Оказалось, скрипт перестал работать полгода назад. (Например - перенесли что-то в другой каталог, а скрипт исполнительно бэкапил прежний каталог). Левел-ап!
Делаем бэкап в два скрипта. Бэкапный скрипт бэкапит. Контролирующий скрипт каждый день шлет назойливые сообщения "ну все окей, мы и сегодня успешно забекапили файл такой-то". Они раздражают, бесят. В инбоксе и так десятки писем. Потом они пропадают (потому что у нас помер и бэкапный скрипт и контролирующий), но в рабочей суете даже и не замечаешь, что они пропали. Потом падает сервер. Левел-ап!
Пробуем "инвертировать" логику контрольного скрипта. Теперь если все ОК - он молчит. А если не ОК (если новых бэкапов не создано) - шлет тревожное письмо. Но.... сами понимаете, как нас это защитить от ситуации, когда сам контрольный скрипт почему-то помер?
Так и дошел до понимания, что единственный надежный контроль за бекапами должен быть:
По принципу watchdog - пока каждый день есть новые бэкапы - он спит, но если сутки прошли, и бэкапов нет (или есть, но почему-то его не оповестили) - поднимает тревогу
Он должен быть внешним. Не зависящим от тех же проблем, которые влияют на вашу систему. В идеале - вообще в другом дата-центре в другой стране.
Он должен ловить простые аномалии (например, если вдруг бэкап стал на 10% меньше чем был вчера - странненько!)
Сейчас он мониторит все - температуру процессоров, load average, протухание SSL сертификатов, то что нужные URLы дают 200, а другие нужные - 403, а третьи - имеют тот же текст, что и раньше (и тревога, если что-то поменялось), итд. Что не умеет мониторить нативно - то можно сделать простым шелл-скриптом (ну или на любом другом языке программирования, просто сделать проверку и print() в нужном формате), но делалось - именно как надежный контроль бэкапов для параноиков.
ky0
Кайф, то есть в какой-то момент вы повторили Заббикс с userparameter в шаблононах :)
xenon
Не знаю, про "заббикс с userparamter в шаблонах", мне он показался излишне сложным и "для другого" (то что в окерре изкоробки, там можно накрутить при должном терпении, но зачем?). Но я в несколько кликов за меньше чем минуту делаю мониторинг нужного доменного имени или сертификата или страницы. А чтобы в каталоге бэкапов он автоматотом начал отслеживать, скажем, бекапы вида serverX-20250714.tar.gz достаточно просто один раз их туда кинуть и больше ничего не делать - автоматически создастся индикатор для serverX и если не будет нового файла сутки - он запаникует, пошлет алерты на почту и в телегу.
Упор не на мониторинг в значении "программа нарисовала график, а ты сиди и смотри в него" (как в графане), а в значении "мониторинг сам мониторит, если что-то не так - получишь алерт". Алерты к каждому индикатору по-умолчанию приделаны (это чтобы их отключить надо пару раз кликнуть, а чтобы включить - ничего кликать не надо, совсем).
Сейчас работаем по принципу, что каждая новая неожиданная проблема может случиться только один раз. А после этого - для нее пишется простая проверка (внутренняя, изнутри сервера, или внешняя). Предсказуемые проблемы (типа протухания сертификатов, кончания места на диске) - предсказываются, непредсказуемые - обнаруживаются и часто фиксятся еще до того, как клиенты позвонят.
Единственное - винду изнутри не может никак мониторить (ну или может - клиентская часть на пайтоне), но не пробовал и упора на это никакого нет. Писалось для своих нужд в первую очередь (небольшая компания с linux, а не гигантские, для которых пишутся большинство зрелых мониторингов), а раз у нас винды нет - то и пофиг на нее :-). Ну и графики там - "так себе" (есть, но упор не на них), для красоты у нас графана есть :-).