Методология разработки программного обеспечения
В этом переводе рассказываем о том, как настроить автомасштабирование контроллера Ingress с использованием Prometheus, KEDA и Locust для генерации трафика.
Практически в каждой организации присутствуют информационные системы, реализованные на платформе 1С.
Описание основных инструментов, их ограничений и способ нивелирования.
Рассказываем, как работать с CI/CD, о шагах при настройке сервера и о полезных командах, которые помогут в работе.
Привет! Меня зовут Николай, я Backend-разработчик в РЕЛЭКС.
В статье ты найдешь полезный теоретический материал, сравнение инструментов CI/CD и подробный гайд по сборке и развертыванию через Docker на удаленный сервер с помощью Gitlab CI/CD — на примере Spring Boot приложения.
Л - Добрый день, дорогие зрители, сегодня мы продолжаем нашу серию репортажей «Стартаперы Кварцевой Лощины». С вами снова я, независимый журналист, Лайер Бала-Больё, и сегодня наш гость - талантливый селфмейд, добившийся всего сам, 19-летний сын известного миллиардера, стартапер Жу̒лико Бары̒гги младший.
Жулико уже выпустил два сверхполезных и сверхнужных приложения, это всем известный SriiPee для заказа пиццы прямо с унитаза и HeyGey – апп для поиска скоплений бородатых мужчин в клетчатых рубашках, любящих фруктовые коктейли и самокаты. Последнее приложение даже автоматически предустанавливается в каждый новый грушефон.
Жулико, вы только что были спикером на проходящем в Сан-Дьябло Блаблатоне и упомянули такую интересную вещь, как ШвабрОпс - можете рассказать нашим зрителям, что это такое и с чем его едят.
Ж – Привет, Лайер, привет всем. Да, на Блаблатоне я рассказывал про ШвабрОпс – это новое перспективное направление в IT. Дело было так. Я маялс…т.е. интенсивно работал в офисе и обратил внимание, что какой-то очкастый толстый задрот ходит туда-сюда из кабинета в кабинет. Я спросил секретаршу – кто это такой? Она ответила – это наш ДевОпс.
Л – Ага.
Ж – А я, если честно, даже не знаю, кто это такой. Но мне тут же в голову пришла идея. А что, если он возьмет в руки швабру и будет протирать пол, пока ходит туда-сюда.
Л – Угу.
Ж – Ну и все, собственно. Я подумал-подумал и решил – а зачем нам уборщица?! Пусть этот дев…как его там…в общем – пусть он еще и пол протирает параллельно. Это же какая экономия получается!
Мы в Авито разработали свою внутреннюю платформу для разработчиков. Несмотря на то, что создание платформенного продукта — довольно затратная история, в итоге мы видим сплошные плюсы. Она растит скорость и качество разработки, делает системы стабильнее, помогает инженерам сосредоточиться на бизнес-задачах, а не на рутине.
Наш опыт построения платформы мы постарались заложить во внешнее решение Plato, которое опирается на проверенные open-source решения.
О преимуществах платформы, процессах её разработки и сложностях в реализации — в этой статье.
В работе с Incident Management-фреймворком мы в инжиниринге преследовали две основные цели: довести uptime до 99,99% (в API / SDK), и всегда знать о проблеме раньше пользователей.
В наши первые дни у нас не было всеобъемлющей системы оповещения и мониторинга. А если и была, то с кучей false-positive алертов и буквально одним-двумя графами в Kibana. Поэтому начать мы решили с создания команды Network Operations Center (NOC) - как стратегического базиса для работы с предотвращением и управлением инцидентами. Мы не только достигли показателя времени безотказной работы в 99,98%, но и увеличили нашу проактивность в выявлении инцидентов заранее: с 60% до впечатляющих 95% и выше. А все благодаря не только активному участию в улучшении платформы со стороны инженерки, но еще и благодаря метрикам First Time to Respond, Time to Acknowledge, Time to Assemble, Proactive Engineering Detection Rate, Number of Critical False Positives. В этом посте я расскажу про каждую из них, какие бывают антипаттерны, как измерять и как улучшать.
Если сейчас запускать проект, то другие идеи, кроме того, чтобы разместиться в облаке не приходят. Облачная инфраструктура дает много преимуществ, но есть проблема — легко не уследить за тратами, забыв про выделенные ресурсы, закупив мощности больше необходимых или используя не самые эффективные решения.
Поэтому мы хотим поделиться советами, как сократить расходы в облаке, они помогут не наступить на грабли тем, кто сейчас в облако переходит и тем, кто уже работает с облачной инфраструктурой. Рекомендации, которые приведены ниже, мы даем нашим клиентам, основываясь на большом опыте работы со множеством облачных провайдеров. Поэтому эти советы вполне можно назвать универсальными.
В марте мы с ИТ-лидером системы Alfa ID и её архитекторами генерировали идеи по повышению стабильности и устойчивости системы, потому что в течение года планировался кратный рост нагрузки. Одной из мыслей, которая потом успешно воплотилась в реальность, была «А давай хаос инжиниринг попробуем? А то мало у нас проблем на проде как-то пока»
Речь пойдёт о трудностях работы инженеров по безопасности в крупной компании – как команда выстроила AppSec и как выбранный подход помог сделать безопаснее “бирюзовую” команду и огромный Enterprise в целом. Это история о самоорганизации, зрелости и уменьшении количества явных контролей в угоду «безопасных» процессов.
В этом нам поможет директор департамента мониторинга и реагирования на инциденты ИБ VK Дмитрий Куколев. У него 12-летний опыт построения процессов безопасного производства. Сейчас он директор департамента мониторинга и реагирования на инциденты ИБ VK.
Использование Foreman и Puppet в подходе IaC.
Foreman предоставляет спектр инструментов для контроля за ИТ-средой, в статье описаны отдельные возможности, такие как: использование Puppet модулей, установка параметров для Puppet, процесс доставки модулей, написание скриптов сбора искомых фактов, использование шаблонов для выгрузки репортов.
Также затронуто использовании программного интерфейса и базы данных
Почти любую инфраструктуру рано или поздно приходится расширять. Если вы — сисадмин в компании с собственными серверами, возможно, для вас этот вопрос стоит не так остро. Но когда работаешь с публичными облаками, вопрос расширения встаёт регулярно. Особенно, если существует несколько регионов.
Установить один сервер раз в месяц — не особенная проблема. Но что делать, если приходится добавлять по 100 серверов в месяц в разные локации? Мы в EdgeCloud для себя ответили на этот вопрос созданием пайплайнов для деплоя серверов. Благодаря этому гениальному решению, как правило, нам даже не приходится заходить на серверы — всё сделает автоматизация.
Почему важно следить за сертификатами: сертификаты – это канал доверия между вашими системами и пользователями. Если канал рушится, доверие пропадает. И это может привести к невиданным техническим и, что еще хуже, бизнес-проблемам.
Поэтому, поговорим о том, как сохранить репутацию, удержать клиентов и обезопасить свой бизнес от неожиданных "сюрпризов" с помощью мониторинга.
В данной статье делюсь замеченной на практике проблемой. Смысл проблемы заключается в использовании противоречащих подходов на уровне Persistance и DevOps.
Каждая стратегия масштабирования имеет свои плюсы и минусы. Почему бы не начать комбинировать их и оставить только плюсы? Поговорим об этом — как сделать хорошо, когда нельзя просто закопать — в контексте PHP.
Данная статья является продолжением статьи - Ивентная модель данных с использованием Kafka и Kafka Connect: Построение гибкой и распределенной архитектуры.
Добро пожаловать во вторую часть статьи о построении гибкой и распределенной архитектуры с использованием Apache Kafka и Kafka Connect! В первой части мы ознакомились с ивентной моделью данных, разработали сервис отправителя и настроили интеграцию с Kafka, чтобы асинхронно отправлять сообщения. Теперь настало время рассмотреть вторую часть этого увлекательного проекта.
Привет, Хабр! Меня зовут Дмитрий Малыхин, последние семь лет я работаю в крупных промышленных компаниях и занимаюсь проектами по цифровизации. Специализируюсь в направлении DevOps — это связь между администраторами, разработчиками и бизнесами. Строю процессы и пытаюсь привнести дух стартапов в крупный энтерпрайз и промышленность.