Задача современного SRE-инженера — сделать так, чтобы система была надежной, стабильной и производительной. Да, это похоже на задачи классического системного администратора, однако в случае с SRE цель достигается немного иными способами.

Reverse Engineering (обратная разработка) представляет собой метод исследования устройств либо программного обеспечения. Основная цель этого исследования — понять принцип работы, а также обнаружить какие-нибудь недокументированные возможности приложения. В сфере информационной безопасности реверс-инжиниринг играет важную роль, ведь именно благодаря ему специалисты из этой области получают возможность изучать вредоносные приложения, разбираясь в нюансах их работы. В последующем это позволяет составлять и обновлять сигнатуры в антивирусных базах, а также защищать обычных и неискушенных в этой сфере пользователей от реальной цифровой угрозы. Давайте посмотрим, какие сегодня существуют методики выполнения обратной разработки.

Kubernetes — очень гибкая платформа, позволяющая запускать рабочие нагрузки именно так, как вам необходимо. Давайте представим, что у вас есть эффективно работающие приложения, которые требуют очень много ресурсной мощности. И, выполнив нагрузочное тестирование, вы, к примеру, обнаружили, что когда действуют дефолтные настройки Kubernetes, одно из этих приложений с большим трудом справляется с ожидаемой нагрузкой трафика. Что делать в данной ситуации?

Kubernetes – это мощная система с открытым исходным кодом, изначально разработанная Google для управления контейнерными приложениями в кластерной среде. Она предоставляет эффективные способы управления связанными распределенными компонентами и услугами в разнообразной инфраструктуре.

Как известно, запускать Spark в Kubernetes можно уже, начиная с версии 2.3, которая была выпущена в 2018 году. При этом до недавнего времени эта возможность была, скажем так, универсальной. Теперь все изменилось.

Что делать, если при попытке работы с Yandex cloud PostgreSQL вы постоянно получаете ошибку "Too many connections for role" или "The connection pool has been exhausted"? Именно с такой проблемой я и столкнулся однажды.

Сегодня мы собираемся погрузиться в то, что такое Terraform, почему он полезен, как он сравнивается с другими инструментами и каковы трудности его использования.

Какова конечная цель практически любой программы? Правильно — решать чьи-либо проблемы, принося деньги создателям. А это означает, что для управленцев тоже нужны (и важны) метрики мониторинга. Что же могут показать такие метрики:

Давайте представим, что у нас есть мониторинг серверов, и выглядит он вполне адекватно: и памяти много, и нагрузка на процессор незначительна. Но это еще далеко не все, ведь если сегодня оборудование неплохо организовано и работает как часы, то завтра можно столкнуться с ситуацией, когда все упало, программы не запущены, а ваши клиенты не могут попасть на сервер. Чтобы такой ситуации не допустить, требуется мониторинг состояния приложений.

Одна из задач DevOps-специалиста может заключаться в обеспечении деплоев в Kubernetes без простоя для разработчиков. Реализовать эту задачу бывает трудно, а все потому, что есть много вариантов завершения работы программных приложений и освобождения этими приложениями использованных ресурсов. Но особые трудности могут возникнуть с Nginx.