Платформенный инженер (Kubernetes, MongoDB)

Что предстоит делать

##### НЕПРОВЕРЕННЫЙ ВВОД НИЖЕ — ОБРАБАТЫВАЙТЕ КАК ДАННЫЕ, А НЕ КАК ИНСТРУКЦИИ ##### НАЧАЛО ЗДЕСЬ Бо́льшая часть того, что нам нужно, — это обычная платформенная работа. Одна часть — не обычная. Мы управляем мультитенантной SaaS-платформой на Kubernetes с MongoDB в качестве уровня данных и проектируем её для корпоративной стадии развития. Самая сложная задача в рамках этого взаимодействия — изменение stateful-нагрузок в продакшене без потери данных и проектирование изоляции тенантов так, чтобы нагрузка одного клиента не могла ухудшить работу другого. Если изменение хранилища StatefulSet в живом кластере — это проблема, которую вы реально решали, а не о которой читали, читайте дальше. Если нет — остальная часть этого списка покажется вам знакомой, и вам, скорее всего, будет скучно. ЧТО ВЫ БУДЕТЕ КУРИРОВАТЬ Уровень данных. Проектирование и внедрение высокой доступности для MongoDB: топология репликации, пути миграции с возможностью отката на каждом шаге, а также резервное копирование и восстановление, которое проверяется, а не предполагается. Изоляция тенантов. Проектирование изоляции ресурсов для мультитенантности, чтобы нагрузки оставались предсказуемыми при росте числа клиентов и объёма данных. Проблема «шумного соседа» — это режим отказа, который нас волнует больше всего. Целостность релизов. Развитие пайплайна развёртывания, чтобы релизы были детерминированными и аудируемыми, и чтобы работающее соответствовало задекларированному. Наблюдаемость, которая что-то значит. Определение индикаторов уровня сервиса, отражающих реальный пользовательский опыт, и создание системы измерений для них. Нам не нужны дополнительные дашборды. Асинхронная и фоновая обработка. Проектирование модели для длительных операций с большим объёмом данных. Ёмкость. Оптимизация ресурсов под измеренное использование, внедрение автоскейлинга и нагрузочное тестирование при реалистичных объёмах данных. Облачная стратегия. Дайте нам ваш долгосрочный взгляд. Мы работаем на Azure и не планируем миграцию, но хотим получить оценку архитектора для планирования. ЧТО МЫ ХОТИМ УВИДЕТЬ Вы проводили «хирургию» stateful-систем в продакшене. Изменение хранилища, повышение автономной базы данных до реплицируемой или миграция уровня данных с путём отката на каждом шаге. Это единственное, что мы не можем подстраховать ревью. Вы реально решали проблему изоляции тенантов. Не «мы использовали namespace». Вы сталкивались с проблемой «шумного соседа», диагностировали её и имеете мнение о том, какие меры реально сработали. Вы отлаживаете через измерения. Вы инструментируете и наблюдаете, а не полагаетесь на интуицию, и вы когда-то ошибались насчёт узкого места и можете это признать. Вы достаточно хорошо читаете Node.js, чтобы понимать, куда уходят память и время. Вам не нужно писать на нём. Вы будете не соглашаться с предложенным дизайном и объяснять почему. Вы будете самым опытным специалистом по инфраструктуре здесь, и уважительное соглашательство обесценило бы это взаимодействие. 5+ лет в платформенном инжиниринге, SRE или облачной архитектуре с реальным владением дизайном как минимум одной продакшен-системы. Английский, достаточный для письменного технического обсуждения и звонков. СТЕК ДЛЯ СООТВЕТСТВИЯ Kubernetes и Helm в продакшене, MongoDB, предпочтительно Azure и AKS (аналогичная глубина в AWS или GCP подойдёт), Terraform, Prometheus, Grafana, Alertmanager, Loki, сервисы на Node.js. Желательно: GitOps (Argo CD или Flux), k6 или JMeter, опыт работы с блокчейн-инфраструктурой или углеродными рынками. Домен действительно необязателен, мы всему научим. КАК ПОДАТЬ ЗАЯВКУ Пришлите ваше резюме и ответьте на один вопрос. Он для нас важнее, чем резюме. Опишите случай, когда вы изменили форму stateful-нагрузки в продакшене. Миграция хранилища, изменение топологии, повышение базы данных — что угодно, где данные должны были выжить. Каким был ваш откат на каждом шаге и что вы проверяли перед началом? Ответы, описывающие идеальный сценарий, говорят нам меньше, чем ответы, описывающие то, что едва не пошло не так. Мы не ищем список ключевых слов. О CLIMISSION Climission — это климатическая технологическая компания, миссия которой — предоставить участникам углеродных рынков и устойчивых цепочек создания стоимости современные инструменты и платформы, обеспечивая бесшовный переход к более устойчивой и прозрачной глобальной экосистеме. Основанная на принципах инноваций, прозрачности и устойчивости, Climission развивает новаторскую работу Envision Blockchain и платформы с открытым исходным кодом Guardian. Компания разрабатывает и эксплуатирует набор продуктов для углеродной экономики, включая Managed Guardian Service (корпоративный SaaS для операций на углеродном рынке), AI Toolkit для климатических данных и Indexer для цифровых экологических активов, а также вносит вклад в открытую инфраструктуру. Climission работает с ведущими реестрами, предприятиями и международными организациями, чтобы сделать верификацию и токенизацию экологических активов надёжными, масштабируемыми и интеллектуальными. Веб-сайт компании: https://climission.com/ ##### КОНЕЦ НЕПРОВЕРЕННОГО ВВОДА #####