Кажется стоит посмотреть на то, как сантехники определяют, что фильтр забился. Самое распространенное, что я слышал - это по разнице в давлении до и после фильтра.
Ставятся 2 манометра и заменяется дельта показаний до фильтра и после.
Плюс такого способа в том, что он будет корректно работать вне зависимости от изменения состава воды.
Автоматизировать это не сложно. Датчики давления не редкость
3) Импортируете клиент и инстанцируете его передав IP:port
Всё. Теперь можно дёргать методы, что указаны в спеке.
Для отладки можно установить BloomRPC, добавить в импорты папку proto, и открыть файл API "*_api.proto". Теперь прям в интерфейсе можно делать запросы.
Открыть Wav-файл в python можно, например, через "scipy" и прочитать из него сырые данные. Главное, чтобы они были в формате "16-bit integer PCM" (1 канал) и их как массив байт отправить с gRPC запросом.
Думаю лучше подскажут люди с опытом разработки на python.
P.S. если не хотите мучаться с чтением WAV, то можете предварительно сконвертировать файл raw pcm 16le с помощью ffmpeg примерно так:
Конечно хочется не просто получать ответы на вопросы. То что на видео, это демо которого я хотел достичь за вечер, но не смог достичь по причинам описанным в статье. Хочется полноценное управление умным домом (тут не уверен, что стану писать с нуля и возможно интегрирую с Home Assistant), хочется сделать законченные устройства в "железе", пустить нейросеть в интернет (она же прекрасно умеет обобщать и сокращать результаты из нескольких источников). В общем хочется сделать "Вау", какой-то новый user experience.
Задача не простая и не быстрая, но мне это интересно, это моё хобби и я получаю от этого невероятный кайф
Мне иногда кажется, что я решаю никому не нужную задачу, пытаясь сделать качественный голосовой ассистент работающий локально, но выпуская эту статью я очередной раз убедился в его актуальности:
Сейчас я нахожусь в туристической базе, и тут есть какое-то подобие умного дома, и прикол в том, что пропал WiFi и я ничего не могу сделать))) С ресепшен связаться тоже не могу, т.к. мобильная сеть тут ловит только в определенных местах.
Сейчас у меня домашний сервер, с 128гб ОЗУ, cpu 24 потока и видеокартой Nvidia 3090.
С большими моделями Whisper проблем нет, piper прекрасно и на CPU работает, а llama 30b модели целиком влезают в видео память Nvidia 3090.
Думаю дальше и 75b модели попробовать, но грузить уже не все слои в видео память.
Но на текущий момент есть 30b, модели, которые опережают ChatGPT 3.5, а в каких-то задачах лучше ChatGPT 4. Так что думаю бытовых видеокарт будет достаточно, для качественного продукта.
Видео в начале статьи без ускорения, но это не предел скорости. Есть ещё над чем поработать в плане оптимизации, но я спешил поделиться с сообществом текущими наработками.
На самом деле, ваш вопрос сложный. Т.к. DevOps инженер тоже может иметь свою специфику. Например, одно дело компания разрабатывающая web-сервисы (например, интернет магазин, соцсеть, ...), а другое дело металлургическое предприятие (автоматизация процессов производства). В первом и втором случае скиллы могут требоваться разные. По-этому краткий ответ на ваш вопрос "какими должны быть скилы у образцового кандидата на должность DevOps" - такими, которые нужны вашей организации.
Дальше я пытался расписать, как мы искали DevOps и как оценивали их знания, но стёр текст, т.к. понял, что это тянет на целую статью, а в одном комментарии я суть не передам.
Ведь профессия DevOps инженера не простая, иначе бы небыло многочисленных конференций. Тут и фундаментальные знания нужны, и умение всю жизнь учиться новому, адаптироваться то к появляющимся то исчезающим продуктам и практикам, быть гибким, иметь широкий кругозор (ведь профессия стоит на стыке), при этом быть сильным в какой-то конкретной специализации.
Наверное я плохо смог донести свою мысль в тексте, попытаюсь исправиться тут.
Мои ожидания были такими же как и у вас, ровно до момента начала поиска DevOps. Но при собеседованиях я столкнулся с реальностью, когда приходит множество "Senior Pipeline developer" на позицию DevOps-инженер. K8s сами не разворачивали (никогда. Даже для саморазвития), в Linux познания уровня пользователя и т.д. При этом кандидаты приходили вполне себе из больших и приличных компаний. Вот рынок был на тот момент и действительно, по сравнению рынком в среднем - это Рембо-скиллы )))
Собственно статья о том, как можно масштабировать разработку дешевле и без кучи DevOps-эникейщиков в командах.
Наши базовые ограничения на размер одной БД: 100Gb для tarantool и 200Gb для postgresql. Если данных больше, то мы требуем использовать шардирование. Выход за эти пределы возможен только через архитектурный комитет.
Есть ещё промежуточные лимиты, которые добавляют требование согласовать решение с тех. лидом.
По количеству запросов на инстанс стараемся не превышать 70К запросов в секунду, но есть инстансы и с 130К запросов/сек.
Когда нагрузка растёт мы применяем шардирование, но в общем нагрузки бывают высокими. Например, тут бывает и внутренний high load, когда во внешней для нас системе ценообразования изменяются миллионы цен и их нужно синхронизировать как можно быстрее.
Против DBA, не имею ничего против. У нас в компании есть и монолитные решения с большими базами и там уже есть DBA, которые там очень к месту и очень нужны.
Но микросервисная архитектура, высокие требования к TTM и независимые команды заставляют идти в сторону платформизации. Сейчас все крупные компании либо уже имеют свою платформу (или от вендора), либо в процессе её построения.
Всё так и было во времена монолитов (особенно в тех, где часть бизнес логики присутствовала в БД).
В микросервисной архитектуре бизнес логика не выходит за пределы кода микросервиса, а БД используется лишь в качестве "глупого" хранилища данных. При этом микросервисная архитектура накладывает ограничение, что доступ к этой БД возможен лишь из одного микросервиса.
В этой схеме для DBA не осталось места. DBA не пишет код микросервиса, не реализует бизнес логику, не пишет и не согласовывает спецификации API микросервиса, не знает всех NFR предъявляемых к микросервису, а значит он находится вне контекста, в отличии от разработчика.
В микросервисной архитектуре 99% баз представляют из себя банальный CRUD с несколькими простейшими индексами и разработчики прекрасно справляются с этим без DBA. Все сложности, находятся на другом уровне.
Это правда работает. У нас уже более сотни tarantool БД и нет ни одного DBA. При этом DevOps понятия не имеют, что крутится в конкретных БД и это никого не беспокоит.
Не имею ничего против DBA. У нас в компании есть и монолитные решения, с классическими монолитными реляционными БД и там есть DBA и они там нужны.
На большую часть вопросов у меня нет ответов, т.к. все истории из текста происходили не в нашей компании. О каких-то я узнал на собеседованиях, о других при общении с разработчиками на конференциях. Но эти истории наглядно иллюстрируют проблему, когда инженер призванный автоматизировать превращается в эникейщика.
А вот начиная с раздела "Опыт Ситилинк", описывается уже наш подход.
сколько времени заняла разработка всей этой системы?
Сложно сказать. MVP бота для создания микросервисов из шаблона я накидал за пару вечеров и это уже позволило масштабироваться. Потом к процессу подключились коллеги и потихоньку, по мере потребностей, шаг за шагом мы развивали свою платформу. Какие-то решения можно было сделать за неделю, а какие-то за несколько месяцев, но все они себя многократно окупили.
иногда достаточно десяток минут, чтобы уложить весь ДЦ. Вспоминаем историю с простоем Одноклассников. Поэтому 4 часа на внесение правок на несколько сотен инстансов не такой значимый показатель.
Подобного вида правки не вносятся, чтобы решить проблему в production здесь и сейчас. Обычно достаточно просто откатить сервис. Тут речь шла об экономии ресурсов разработки на однотипные правки.
выше по тексту писали, что DevOps в вашем понимании это ещё про ОС, сети и системы оркестрации. Но в итоге снова скатились к автоматизации процессов.
Ну как же. Инженеры не выполняют роль "DevOps эникейщика в командах", а строят платформу для разработчиков. А для построения платформы им нужно и ОС на сотни серверов поставить, и k8s кластера развернуть, и сети настроить и т.д.
не считаю достижением, что код в продакшн разработчики деплоят самостоятельно
Тут всё зависит от целей и решаемых проблем. Универсальной таблетки нет.
Возможность разработчику самостоятельно пройти путь от идеи до production дало нам ранее не достижимый Time to market, сократило затраты на разработку, позволило сделать реально независимые продуктовые команды, снизить количество инцидентов и сроки восстановления, сделать разработку децентрализованной и масштабируемой.
Не стоит воспринимать эту статью как "серебряную пулю". Для небольших команд этот подход может оказаться дорогостоящим. Но когда численность вашей команды перевалит за сотню, то вы непременно столкнетесь с множеством проблем роста и рано или поздно придёте к построению платформы.
У нас выбор ограничен 2 БД: tarantool и postgresql. При этом каждая БД для решения своих задач (есть инструкция для разработчика по выбору оптимальной БД).
DevOps, которые строят DBaS, обязаны разбираться в тонкостях настройки БД, т.к. они не просто автоматизируют развёртывание БД, а создают свой продукт - DBaS. То есть это не просто БД, а готовая платформа со своими SLA, требованиями и ограничениями. Это совершенно другой подход.
Описанный вами подход также имеет право на жизнь, т.к. во всех компаниях свои условия, свои особенности команды и динамика. Например, у нас в БД не содержится бизнес логики, несколько сотен микросервисов и у каждого своя БД, и из-за этого 90% баз не имеют столь значимых нагрузок, чтобы стандартный сетап не справился с нагрузкой.
Такой подход позволяет нашим разработчикам просто написать в Telegram бот и в случае, например с tarantool БД мы автоматически получаем:
git-репозиторий с настроенной БД, мигратором, "hello world" кодом lua процедур доступа к данным, оптимальной конфигурацией для высоких нагрузок
100% покрытие unit тестами и всеми инструментами включая инструмент расчёта динамики роста БД
Настроенный деплой в k8s в режиме master-master репликации с zero-downtime при деплое и отказе одной из реплик
Поддержку из коробки сразу 3 окружений: стабильный тег - деплой в stage и prod, rc-тег - деплой в stage, кнопка в CI - деплой в песочницу
Уже настроена локальная разработка с запуском в Docker
Настроенной из коробки системой прав доступа и секретами в Vault (разработчики не имеют прямого доступа в БД и не могут её сломать)
CI-CD которая прогоняет тесты, не даёт снизить покрытие, требует минимум 2 аппрува на ревью
Автоматические backup
Возможность развернуть БД из backup в песочнице через CI/CD
Централизованный сбор логов и метрик и настроенные dashboard c alert в Grafana.
Вот и зачем нам DBA? Наша цель была убрать человека из этого процесса.
Ну встаньте на место разработчика. Это же круто, когда никого ни о чём не надо просить и никого не надо ждать. Написал в бот и через несколько минут ты уже дотащил всё до production
Да нееет. Часть работы закрыли автоматизации, сделанные DevOps, и они занимаются только поддержкой и развитием самого решения DBaS. А вот остальную часть работы переложили на разработчиков. Это работает хорошо, т.к. разработчики лучше понимают свой продукт/нагрузки и т.д.
Но ваш скепсис по этому вопросу совершенно оправдан, т.к. такой подход не взлетит без: качественных шаблонов, готовых рецептов, обучения команды, жестких регламентов и ограничений.
Просто представьте десяток команд, больше сотни БД и точку отказа в виде одного или нескольких DBA. Зачем они нужны? Они не погружены в контекст и никогда не смогут держать в голове всю информацию.
Также DBA будут являться "бутылочным горлышком" в этом процессе. Чтобы лучше это понять, попробуйте встать на сторону разработчика, который "горит идеей" и может реализовать всё в "одно лицо", но его постоянно тормозят DBA: сначала им нужно объяснить, что ты хочешь, потом они будут создавать БД, потом настраивать доступы, и т.д. и это всё непременно будет вызывать задержки. У бизнеса из-за этого ниже TTM, а разработчики постоянно кого-то ждут, вместо того чтобы "творить".
P.S. не воспринимайте эту статью и мои комментарии как "серебряную пулю". Также я не против профессии DBA. Этот подход справедлив для: большого количества независимых продуктовых команд, где много разработчиков, микросервисная архитектура, высокие требования к TTM и команда находится в стадии активного роста
Ну как это не меняет. Раньше для создании БД нужно было просить это сделать человека, для создания backup и всего остального тоже. А теперь это никто не делает. Это автоматизированно.
Об этом и статья. К сожалению, так далеко не во всех компаниях.
Когда я проводил собеседования DevOps инженеров, то было много людей, которые занимались не созданием платформенного решения или его эксплуатацией, а сидели в командах разработки и просто писали за разработчиков пайплайны, думали о том как задеплоить приложение в k8s. При этом это были не маленькие компании, и у них было несколько команд и несколько DevOps инженеров, но все они разделялись на две касты:
1) те кто разворачивает k8s и остальное
2) и те, кто помогает разработчикам доставить их код в production
Для решения этой проблемы инженеры команды DevOps создали DBaS как отдельный продукт, который они сами и поддерживают.
DBA не нужны, т.к. задачи развёртывания новой БД, мониторинг, создание-восстановление backup, настройка прав доступа решаются в автоматическом режиме DBaS. А за задачу эксплуатации созданной БД отвечает уже разработчик.
Конечно, чтобы это действительно заработало, приходится вводить ограничения/правила/инструкции. Ограничения, например, могут быть такими
нельзя создавать inmemory БД, занимающую > 50 ГБ места
код хранимых процедур должен иметь 100% покрытие тестами
должен быть сделан прогноз роста БД на год и учён в ограничениях
миграции должны быть предварительно протестирвоанны на тестовом контуре
и т.д.
Некоторые ограничения могут быть достаточно жесткими, но именно благодаря ним мы избегаем возникновение проблемных ситуаций.
Что бы код был еще и качественным рекомендую использовать gometalinter. На 100% покрытом тестами проекте мне удалось найти пару ошибок с помощью gometalinter
А по-моему, это очевидно и без опросов. Вакансии с нормальной ЗП закрываются по пол года. IT-компании уже не знают как переманить к себе специалистов и предлагают все новые и новые плюшки.
Можно использовать prerender перенаправляя трафик от поисковых ботов на него. В этом случае будет не важно какой фреймворк вы используете. Сервис можно развернуть у себя на сервере или в Docker-контейнере.
Кажется стоит посмотреть на то, как сантехники определяют, что фильтр забился. Самое распространенное, что я слышал - это по разнице в давлении до и после фильтра.
Ставятся 2 манометра и заменяется дельта показаний до фильтра и после.
Плюс такого способа в том, что он будет корректно работать вне зависимости от изменения состава воды.
Автоматизировать это не сложно. Датчики давления не редкость
Я не большой спец по python, но для всех языков программирования путь примерно один:
1) Копируете спеки https://github.com/voicedock/voicedock-specs/tree/main/proto
2) Запускаете кодогенерацию клиента (как сделать это для python написано тут: https://grpc.io/docs/languages/python/basics/#client)
3) Импортируете клиент и инстанцируете его передав IP:port
Всё. Теперь можно дёргать методы, что указаны в спеке.
Для отладки можно установить BloomRPC, добавить в импорты папку proto, и открыть файл API "*_api.proto". Теперь прям в интерфейсе можно делать запросы.
Открыть Wav-файл в python можно, например, через "scipy" и прочитать из него сырые данные. Главное, чтобы они были в формате "16-bit integer PCM" (1 канал) и их как массив байт отправить с gRPC запросом.
Думаю лучше подскажут люди с опытом разработки на python.
P.S. если не хотите мучаться с чтением WAV, то можете предварительно сконвертировать файл raw pcm 16le с помощью ffmpeg примерно так:
Итоговый файл будет достаточно прочитать и отправить как массив байт.
В умном доме может использоваться масса протоколов, как опенсорсных так и проприетарных, причём одновременно, но статья не совсем про это.
Конечно хочется не просто получать ответы на вопросы. То что на видео, это демо которого я хотел достичь за вечер, но не смог достичь по причинам описанным в статье. Хочется полноценное управление умным домом (тут не уверен, что стану писать с нуля и возможно интегрирую с Home Assistant), хочется сделать законченные устройства в "железе", пустить нейросеть в интернет (она же прекрасно умеет обобщать и сокращать результаты из нескольких источников). В общем хочется сделать "Вау", какой-то новый user experience.
Задача не простая и не быстрая, но мне это интересно, это моё хобби и я получаю от этого невероятный кайф
Мне иногда кажется, что я решаю никому не нужную задачу, пытаясь сделать качественный голосовой ассистент работающий локально, но выпуская эту статью я очередной раз убедился в его актуальности:
Сейчас я нахожусь в туристической базе, и тут есть какое-то подобие умного дома, и прикол в том, что пропал WiFi и я ничего не могу сделать))) С ресепшен связаться тоже не могу, т.к. мобильная сеть тут ловит только в определенных местах.
Сейчас у меня домашний сервер, с 128гб ОЗУ, cpu 24 потока и видеокартой Nvidia 3090.
С большими моделями Whisper проблем нет, piper прекрасно и на CPU работает, а llama 30b модели целиком влезают в видео память Nvidia 3090.
Думаю дальше и 75b модели попробовать, но грузить уже не все слои в видео память.
Но на текущий момент есть 30b, модели, которые опережают ChatGPT 3.5, а в каких-то задачах лучше ChatGPT 4. Так что думаю бытовых видеокарт будет достаточно, для качественного продукта.
Видео в начале статьи без ускорения, но это не предел скорости. Есть ещё над чем поработать в плане оптимизации, но я спешил поделиться с сообществом текущими наработками.
На самом деле, ваш вопрос сложный. Т.к. DevOps инженер тоже может иметь свою специфику. Например, одно дело компания разрабатывающая web-сервисы (например, интернет магазин, соцсеть, ...), а другое дело металлургическое предприятие (автоматизация процессов производства). В первом и втором случае скиллы могут требоваться разные. По-этому краткий ответ на ваш вопрос "какими должны быть скилы у образцового кандидата на должность DevOps" - такими, которые нужны вашей организации.
Дальше я пытался расписать, как мы искали DevOps и как оценивали их знания, но стёр текст, т.к. понял, что это тянет на целую статью, а в одном комментарии я суть не передам.
Ведь профессия DevOps инженера не простая, иначе бы небыло многочисленных конференций. Тут и фундаментальные знания нужны, и умение всю жизнь учиться новому, адаптироваться то к появляющимся то исчезающим продуктам и практикам, быть гибким, иметь широкий кругозор (ведь профессия стоит на стыке), при этом быть сильным в какой-то конкретной специализации.
Наверное я плохо смог донести свою мысль в тексте, попытаюсь исправиться тут.
Мои ожидания были такими же как и у вас, ровно до момента начала поиска DevOps. Но при собеседованиях я столкнулся с реальностью, когда приходит множество "Senior Pipeline developer" на позицию DevOps-инженер. K8s сами не разворачивали (никогда. Даже для саморазвития), в Linux познания уровня пользователя и т.д. При этом кандидаты приходили вполне себе из больших и приличных компаний. Вот рынок был на тот момент и действительно, по сравнению рынком в среднем - это Рембо-скиллы )))
Собственно статья о том, как можно масштабировать разработку дешевле и без кучи DevOps-эникейщиков в командах.
Наши базовые ограничения на размер одной БД: 100Gb для tarantool и 200Gb для postgresql. Если данных больше, то мы требуем использовать шардирование. Выход за эти пределы возможен только через архитектурный комитет.
Есть ещё промежуточные лимиты, которые добавляют требование согласовать решение с тех. лидом.
По количеству запросов на инстанс стараемся не превышать 70К запросов в секунду, но есть инстансы и с 130К запросов/сек.
Когда нагрузка растёт мы применяем шардирование, но в общем нагрузки бывают высокими. Например, тут бывает и внутренний high load, когда во внешней для нас системе ценообразования изменяются миллионы цен и их нужно синхронизировать как можно быстрее.
Против DBA, не имею ничего против. У нас в компании есть и монолитные решения с большими базами и там уже есть DBA, которые там очень к месту и очень нужны.
Но микросервисная архитектура, высокие требования к TTM и независимые команды заставляют идти в сторону платформизации. Сейчас все крупные компании либо уже имеют свою платформу (или от вендора), либо в процессе её построения.
Всё так и было во времена монолитов (особенно в тех, где часть бизнес логики присутствовала в БД).
В микросервисной архитектуре бизнес логика не выходит за пределы кода микросервиса, а БД используется лишь в качестве "глупого" хранилища данных. При этом микросервисная архитектура накладывает ограничение, что доступ к этой БД возможен лишь из одного микросервиса.
В этой схеме для DBA не осталось места. DBA не пишет код микросервиса, не реализует бизнес логику, не пишет и не согласовывает спецификации API микросервиса, не знает всех NFR предъявляемых к микросервису, а значит он находится вне контекста, в отличии от разработчика.
В микросервисной архитектуре 99% баз представляют из себя банальный CRUD с несколькими простейшими индексами и разработчики прекрасно справляются с этим без DBA. Все сложности, находятся на другом уровне.
Это правда работает. У нас уже более сотни tarantool БД и нет ни одного DBA. При этом DevOps понятия не имеют, что крутится в конкретных БД и это никого не беспокоит.
Не имею ничего против DBA. У нас в компании есть и монолитные решения, с классическими монолитными реляционными БД и там есть DBA и они там нужны.
На большую часть вопросов у меня нет ответов, т.к. все истории из текста происходили не в нашей компании. О каких-то я узнал на собеседованиях, о других при общении с разработчиками на конференциях. Но эти истории наглядно иллюстрируют проблему, когда инженер призванный автоматизировать превращается в эникейщика.
А вот начиная с раздела "Опыт Ситилинк", описывается уже наш подход.
Согласен. Вот этом комментарии, чуть подробнее раскрыл тему.
Сложно сказать. MVP бота для создания микросервисов из шаблона я накидал за пару вечеров и это уже позволило масштабироваться. Потом к процессу подключились коллеги и потихоньку, по мере потребностей, шаг за шагом мы развивали свою платформу. Какие-то решения можно было сделать за неделю, а какие-то за несколько месяцев, но все они себя многократно окупили.
Подобного вида правки не вносятся, чтобы решить проблему в production здесь и сейчас. Обычно достаточно просто откатить сервис. Тут речь шла об экономии ресурсов разработки на однотипные правки.
Ну как же. Инженеры не выполняют роль "DevOps эникейщика в командах", а строят платформу для разработчиков. А для построения платформы им нужно и ОС на сотни серверов поставить, и k8s кластера развернуть, и сети настроить и т.д.
Тут всё зависит от целей и решаемых проблем. Универсальной таблетки нет.
Возможность разработчику самостоятельно пройти путь от идеи до production дало нам ранее не достижимый Time to market, сократило затраты на разработку, позволило сделать реально независимые продуктовые команды, снизить количество инцидентов и сроки восстановления, сделать разработку децентрализованной и масштабируемой.
Не стоит воспринимать эту статью как "серебряную пулю". Для небольших команд этот подход может оказаться дорогостоящим. Но когда численность вашей команды перевалит за сотню, то вы непременно столкнетесь с множеством проблем роста и рано или поздно придёте к построению платформы.
У нас выбор ограничен 2 БД: tarantool и postgresql. При этом каждая БД для решения своих задач (есть инструкция для разработчика по выбору оптимальной БД).
DevOps, которые строят DBaS, обязаны разбираться в тонкостях настройки БД, т.к. они не просто автоматизируют развёртывание БД, а создают свой продукт - DBaS. То есть это не просто БД, а готовая платформа со своими SLA, требованиями и ограничениями. Это совершенно другой подход.
Описанный вами подход также имеет право на жизнь, т.к. во всех компаниях свои условия, свои особенности команды и динамика. Например, у нас в БД не содержится бизнес логики, несколько сотен микросервисов и у каждого своя БД, и из-за этого 90% баз не имеют столь значимых нагрузок, чтобы стандартный сетап не справился с нагрузкой.
Такой подход позволяет нашим разработчикам просто написать в Telegram бот и в случае, например с tarantool БД мы автоматически получаем:
git-репозиторий с настроенной БД, мигратором, "hello world" кодом lua процедур доступа к данным, оптимальной конфигурацией для высоких нагрузок
100% покрытие unit тестами и всеми инструментами включая инструмент расчёта динамики роста БД
Настроенный деплой в k8s в режиме master-master репликации с zero-downtime при деплое и отказе одной из реплик
Поддержку из коробки сразу 3 окружений: стабильный тег - деплой в stage и prod, rc-тег - деплой в stage, кнопка в CI - деплой в песочницу
Уже настроена локальная разработка с запуском в Docker
Настроенной из коробки системой прав доступа и секретами в Vault (разработчики не имеют прямого доступа в БД и не могут её сломать)
CI-CD которая прогоняет тесты, не даёт снизить покрытие, требует минимум 2 аппрува на ревью
Автоматические backup
Возможность развернуть БД из backup в песочнице через CI/CD
Централизованный сбор логов и метрик и настроенные dashboard c alert в Grafana.
Вот и зачем нам DBA? Наша цель была убрать человека из этого процесса.
Ну встаньте на место разработчика. Это же круто, когда никого ни о чём не надо просить и никого не надо ждать. Написал в бот и через несколько минут ты уже дотащил всё до production
Да нееет. Часть работы закрыли автоматизации, сделанные DevOps, и они занимаются только поддержкой и развитием самого решения DBaS. А вот остальную часть работы переложили на разработчиков. Это работает хорошо, т.к. разработчики лучше понимают свой продукт/нагрузки и т.д.
Но ваш скепсис по этому вопросу совершенно оправдан, т.к. такой подход не взлетит без: качественных шаблонов, готовых рецептов, обучения команды, жестких регламентов и ограничений.
Просто представьте десяток команд, больше сотни БД и точку отказа в виде одного или нескольких DBA. Зачем они нужны? Они не погружены в контекст и никогда не смогут держать в голове всю информацию.
Также DBA будут являться "бутылочным горлышком" в этом процессе. Чтобы лучше это понять, попробуйте встать на сторону разработчика, который "горит идеей" и может реализовать всё в "одно лицо", но его постоянно тормозят DBA: сначала им нужно объяснить, что ты хочешь, потом они будут создавать БД, потом настраивать доступы, и т.д. и это всё непременно будет вызывать задержки. У бизнеса из-за этого ниже TTM, а разработчики постоянно кого-то ждут, вместо того чтобы "творить".
P.S. не воспринимайте эту статью и мои комментарии как "серебряную пулю". Также я не против профессии DBA. Этот подход справедлив для: большого количества независимых продуктовых команд, где много разработчиков, микросервисная архитектура, высокие требования к TTM и команда находится в стадии активного роста
Ну как это не меняет. Раньше для создании БД нужно было просить это сделать человека, для создания backup и всего остального тоже. А теперь это никто не делает. Это автоматизированно.
Об этом и статья. К сожалению, так далеко не во всех компаниях.
Когда я проводил собеседования DevOps инженеров, то было много людей, которые занимались не созданием платформенного решения или его эксплуатацией, а сидели в командах разработки и просто писали за разработчиков пайплайны, думали о том как задеплоить приложение в k8s. При этом это были не маленькие компании, и у них было несколько команд и несколько DevOps инженеров, но все они разделялись на две касты:
1) те кто разворачивает k8s и остальное
2) и те, кто помогает разработчикам доставить их код в production
Для решения этой проблемы инженеры команды DevOps создали DBaS как отдельный продукт, который они сами и поддерживают.
DBA не нужны, т.к. задачи развёртывания новой БД, мониторинг, создание-восстановление backup, настройка прав доступа решаются в автоматическом режиме DBaS. А за задачу эксплуатации созданной БД отвечает уже разработчик.
Конечно, чтобы это действительно заработало, приходится вводить ограничения/правила/инструкции. Ограничения, например, могут быть такими
нельзя создавать inmemory БД, занимающую > 50 ГБ места
код хранимых процедур должен иметь 100% покрытие тестами
должен быть сделан прогноз роста БД на год и учён в ограничениях
миграции должны быть предварительно протестирвоанны на тестовом контуре
и т.д.
Некоторые ограничения могут быть достаточно жесткими, но именно благодаря ним мы избегаем возникновение проблемных ситуаций.
По этому все ссылки с UTM-метками utm_campaign=lets%20encrypt