Как только у сотрудника какой-либо компании появляется необходимость выполнять задачи на мобильных устройствах (пусть даже элементарно читать рабочую почту) и, соответственно, получать с них доступ к данным компании, появляются риски. Мобильные устройства (как и все эндпоинты) подвержены ряду уязвимостей — приложения, установленные не через официальные магазины, могут оказаться вредоносными; подключение к незащищенной Wi-Fi-сети может привести к утечке данных; устройство может быть утеряно или украдено… Отсюда возникают самые популярные сценарии управления устройствами — удаленное стирание данных, ограничение на источники установки приложений, требования к используемым сетям, запрет копирования конфиденциальных данных (например, на внешний носитель) и другие.
Тут-то и появляется необходимость в MDM, или Mobile Device Management, — наборе сервисов для защиты мобильных устройств сотрудников компании.
Меня зовут Мария Глущенко (@mglushchenko), я —— Android-разработчик. В этой статье расскажу, какие режимы доступны для ОС Android и как реализовывать их функционал, в чем преимущества и недостатки этих решений и как мы их используем в мобильной команде «Лаборатории Касперского».
Привет! Меня зовут Александр Лебедев, я SRE в Samokat.tech. Мы строим надёжную платформу для сервисов быстрой доставки и в зону ответственности моей команды входят поддержка Kubernetes-кластеров и управление их ресурсами.
Под катом история о том, как мы пришли к своему варианту resource management через борьбу с овербукингом по CPU.
В прошлом материале мы рассказали, с какой проблемой столкнулись, и проанализировали четыре СУБД в поиске рабочего решения. Мы оценили преимущества и недостатки каждого отобранного варианта и остановились на ClickHouse. Несмотря на то, что готовой интеграции этой БД с Zabbix не существует, CH отлично подходил как решение под наши инженерные задачи.
БД в Zabbix
Прежде чем мы перейдем к рассказу о реализации, расскажем о специфике работы БД в Zabbix. Вся ее логика вынесена в отдельную библиотеку — zbxhistory. Она используется сервером и прокси для сохранения данных мониторинга. В классе history описывается интерфейс, который имплементируется каждой реализацией подключения к хранилищу данных.
Недавно в нашу компанию «Инфосистемы Джет» пришел заказчик с проблемой долгой реализации создаваемых портов на NSX-T (до 2 минут до момента запуска трафика). Основная боль заключалась в том, что новые поды K8s не всегда укладывались в timeout Health Check'a и процесс начинался опять.
Исходные данные у нас были такие. NSX использовался для построения микросегментированной сети в кластерах Kybernetes + Kyverno. Взаимодействие K8s и NSX было реализовано при помощи плагина VMware NCP. Несмотря на большое количество объектов, в интерфейсе все метрики по утилизации были в «зеленых» значениях, но ощущалось сильное замедление работы UI.
Недавно решая проблему заказчика – крупного ритейлера, мы значительно ускорили работу одного из процессов, реализованных в SAP ERP. Периодически задания по загрузке цен работали ооооооооооооооооооооооооооочень медленно, причем задержка составляла не каких-нибудь 10 минут, а могла доходить до нескольких часов.
Для сравнения приводим два скрина. На первом отображено нормальное время выполнения задачи:
Пришёл ученик к мастеру. И спросил:
— Что вы делали до просветления? Как жили?
Мастер ответил:
— Колол дрова, носил воду, готовил еду.
— А что вы делаете после просветления? — спросил ученик.
— Колю дрова, ношу воду, готовлю еду, — ответил мастер.
— А что изменилось?
— Да всё!
Привет, меня зовут Сергей — я руководитель DevOps-направления KTS.
Рассмотрим относительно новый виток в развитии деплоя приложений и посмотрим, какие вопросы можно закрыть с помощью инструмента Argo CD.
GitOps — это одна из реализаций Pull-модели, в которой Git является хранилищем всех конфигураций. Источник правды — Git, все изменения в инфраструктуре проходят только через него. Все изменения по Pull-модели проводит специальный агент, который затем поддерживает заданное состояние. То есть если внести в инфраструктуру изменения вручную, агент увидит несоответствие с тем, что есть в Git, и вернёт все к нужному состоянию, идентичному источнику правды.
Argo CD — один из самых популярных GitOps-инструментов. Он живет внутри Kubernetes и там же развертывает сущности. Argo CD предоставляет удобный RBAC, то есть управление правами и доступами. В интерфейсе можно посмотреть свои действия, управлять приложениями и принудительно синхронизировать их. Argo CD входит в CNCF, что вызывает к нему большое доверие.
Привет, Хабр! Меня зовут Сергей Баширов, я ведущий разработчик в Cloud.ru. Наша команда RnD занимается исследованиями и оптимизацией баз данных, файловых систем, объектных хранилищ, СХД и SDS в облачной инфраструктуре. И мы решили «импортозаместить в лучших традициях» вендорские решения на базе pNFS. За дело взялись вместе с моим коллегой — Константином Евтушенко (@kevtushx).
К сожалению менеджеров и на радость нам, годной инструкции по настройке в интернете не оказалось. Софт с открытым исходным кодом из коробки не завелся: пришлось погружаться в детали, отлаживать и чинить. В статье расскажу, как всё было, какие ошибки и выводы мы сделали, а также поделюсь подробной инструкцией по настройке стенда с блочным типом доступа к серверам данных. Если интересно — добро пожаловать под кат!
Чтобы развивать наши продукты осмысленно, мы регулярно проводим исследования с участием пользователей. И на этот раз пообщались с людьми, чей опыт работы с ПО заслуживает отдельного внимания — администраторами приложений.
Разумеется, администратор — это не конечный пользователь, и далеко не всегда его мнение соответствует общему мнению о продукте. Вместе с тем он ключевая фигура в работе ИТ-системы: то, насколько успешно он справляется с задачами по её настройке и обслуживанию, влияет на комфорт и эффективность остальных пользователей. Значит, сделав что-то хорошее для администратора, мы помогаем в работе многим другим.
Мы провели наше первое исследование среди администраторов и не избежали ряда ошибок. Но также сделали важные выводы — и составили чеклист, который в будущем поможет планировать подобные исследования на более качественном уровне.
Под катом делимся полученными знаниями: возможно, с их помощью вы не наступите на те же грабли, что и мы.
Привет, меня зовут Сергей Качеев, я старший разработчик в отделе сетевой инфраструктуры Яндекса. Сегодня я расскажу целый сетевой детектив о том, как мы искали баг, который убивал DNS сервер Unbound. Приготовьтесь, он будет долгим.
Всё началось с того, что мне предложили помочь ребятам из команды DNS найти такие метрики и наборы запросов, по которым будет однозначно понятно, какие настройки влияют на производительность Unbound и какие запросы вызывают у него проблемы.
В самом начале на графиках нагрузочного тестирования я увидел очень плохие результаты: случайным образом абсолютно все запросы нагрузочного теста таймаутились, но сервер, который был под нагрузкой, никак не реагировал на проблему. Как выяснилось позже, по чистой случайности я допустил ошибку в конфигурации нашего плагина Pandora, и в итоге он сам ходил в DNS на каждый запрос, чтобы узнать ip адрес тестируемого сервера. Возможно, это сыграло мне на руку и помогло найти первую из проблем, а потом и вовсе задало вектор поисков остальных багов. А в Unbound их накопилось достаточно.