Предыдущая часть: habrahabr.ru/post/118475

В этой части: подробнее о жизни эникейщика: как устроиться, чем заниматься, чего избегать, к чему стремиться.

Я откладываю вопрос о «будущем сисадмина» на следующие части — сейчас я сфокусируюсь на том, как начинается карьера. Повторю, опытным администраторам всё это будет казаться либо обидным, либо очевидным — но я достаточно посмотрел за эту весну на людей, которые пытаются «вскочить в индустрию», но у них не получается. Именно для них этот цикл статей. (Я не ощущаю себя достаточно умным, чтобы рассказывать про будущее карьеры для людей, у которых опыта, возможно, больше, чем у меня).

Вступление

Примерно до середины 2000ых было два пути стать системным администратором: через путь эникейщика и через профильное высшее образование (обычно, в всякого рода институтах связи). Первое давало много опыта, второе — довольно много знаний (из которых большая часть не нужна). Сейчас появился третий — всякого рода «курсы системного администрирования», которые, реально, тлен и прах (если судить по тому, что знают и умеют те, кто их закончил).

Так получилось, что эту весну я провёл в поисках/собеседованиях людей аж на четыре вакансии, связанные с системным администрированием. Я пообщался с несколькими десятками людей и заметил характерные ошибки и проблемы, с которыми они сталкиваются. Излагаю то, что заметил, а так же свои мысли, как эти проблемы решить.

scope: начинающие системные администраторы, помощники системных администраторов и т.д. Опытным администраторам, а так же тем, кто имеет вполне конкретную специализацию будет если и интересно, то бесполезно.

Примерная структура цикла статей — я опишу то, как мне видится профессия системного администратора, разберу текущее отношение к профессии со стороны работодателя, потом попробую дать общую информацию о том, с чего начинать и куда двигаться дальше.

Какие бывают системные администраторы?

Мы продолжаем нашу серию статей о центре сертификации на предприятии. Сегодня поговорим о построении диаграммы открытого ключа, планировании имен центра сертификации, планировании списков отзыва сертификатов и еще нескольких моментах. Присоединяйтесь!

Кажется не так давно это было, примерно в 2015 году, мы начали слышать о хакерах, не использовавших вредоносных программ внутри периметра атакуемой цели. А использовали они то, что было под рукой – это были различные инструменты, находившиеся на целевом сайте. Это оказалось идеальным способом, чтобы сделать свое «грязное дело» не поднимая лишнего «шума».

Этот подход в наше время набрал обороты и стал мейнстримом, в первую очередь из-за обилия готовых инструментариев хакеров, таких как PowerShell Empire.

Появилась необходимость сменить основной домен компании в G Suite с .ru на .com с сохранением всех данных, календарей, псевдонимов и доступов на сторонние ресурсы. Информации о переезде в интернете не очень много, а точнее, кроме справки самого Google, вообще ничего не нашлось, что и стало причиной создания этого how-to. Будет полезно, если кто-то решит повторить подобное.

Дело в том, что изначально в компании использовался домен pixonic.ru. Затем был добавлен псевдоним pixonic.com, но везде по умолчанию стояла почта в зоне .ru. А так как многие сотрудники компании ведут переписку с зарубежными коллегами и клиентами, было желание использовать международный формат. Для этого им приходилось заходить в настройки аккаунта, самостоятельно менять основной почтовый адрес и приводить подпись в соответствие с корпоративным шаблоном. Не все это делали (или делали, но через раз) и можно представить, какой беспорядок и путаница творились в ветках сообщений. Для внешних партнеров это выглядело еще менее презентабельно из-за разных подписей.

В общем, настал момент, когда было решено — вся переписка должна вестись с использованием почты pixonic.com. Задача упала на нас — системных администраторов.

В конце статьи есть ссылка на весь скрипт, поэтому в тексте будут лишь его куски.

Всем привет! Меня зовут Алексей, я тимлид команды Vimbox (платформа для обучения в Skyeng). Не так давно я выступал на конференции с докладом об удаленной работе и особенностях распределенной команды. Неожиданно темой заинтересовалось много людей, хотя я думал, что хайп уже прошел и никого не удивить. Поэтому я решил поделиться и с вами наработками, полученными за четыре года функционирования в этом формате. Поскольку у нас в компании из 55 разработчиков 51 человек постоянно работает вне офиса, да и сам я живу в Калининграде, думаю, наш опыт многим может пригодиться.

Добрый день!

Все чаще стучась в различные компании разработчиков в качестве DevOps инженера, я получаю приблизительно одни и те же тестовые задания. Они отличаются друг от друга версиями PHP или проектами которые надо запустить.

Но в целом они упираются в одну связку это Nginx\Appache, SQL (тут вариаций много, все зависит от предпочтений заказчика), PHP и желательно чтобы это было разложено по контейнерам.
Поэтому я решил рассказать на примере, как все это поднять без особых усилий.

Возможно кому-то это поможет понять, на простом примере, что к чему. Описывать что такое Docker я не буду, т.к. статей на эту тему вагон и маленькая тележка.

В данной статье, мы подготовим небольшую структуру:

• В качестве вэб сервера будет использоваться Nginx с минимальной настройкой для запуска проекта.
• В качестве SQL будет использовать MySQL.
• PHP7.0-fpm версия c небольшими надстройками для запуска нашего проекта.
• В качестве проекта который мы будем разворачивать — берем magento2.

Добрый день, вечер или ночь, все зависит от времени суток в который вам довелось прочитать мою статью.

В связи с ростом количества корпоративных клиентов, было принято решение дать доступ к учетной системе внешним пользователям. Для самостоятельного оформления заказов и отслеживания их состояний. Реализация была создан web интерфейс с необходимым функционалом и доступом. Тут же стал вопрос безопасности, кроме стандартных пользователь-пароль было решено еще усилить безопасность, для этого применили OpenVPN, но появились клиенты, для которых нельзя применять OpenVPN (политики безопасности, нежелания и.д.), тут на глаза попались статьи про доступ по ssl сертификату.

Скажем сразу: для нас этот проект особенный. Внедрения VDI на 50, 250 и даже 2500 пользователей в нашей практике уже бывали. Но всё меняется, когда речь заходит об инсталляциях, насчитывающих свыше десятка тысяч рабочих мест. Сервис автоматически становится бизнес-критичным, и требования по доступности выходят на первый план.

2 года безвылазной совместной работы с заказчиком, сотни согласований, горы технической документации, масса тестирований на большом количестве разнородного прикладного ПО и периферийного оборудования, огромное количество подводных камней и седых волос…
Но и результат не менее масштабный: VDI позволила модернизировать и объединить ИТ-инфраструктуры сразу трех банков — ВТБ, ВТБ24 и Банка Москвы. А нам теперь, пожалуй, любой VDI по плечу. Подробности — в блоге ВТБ.

Существует огромное количество инструментов визуализации графиков, умеющих делать с ними настоящие чудеса. Все они имеют разное назначение и специализацию.

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

В большой организации работа централизованных служб часто имеет критическое значение.

Представьте, что Вы – руководитель службы поддержки, состоящей из 10 человек, и Ваша команда обслуживает коллектив из 200 команд, в каждой из которой по 7-10 человек. Это минимум 1400 человек, ежедневно засыпающих Вас работой.

Теперь добавим сюда ещё больше реальности и представим, что Вы выполняете некую централизованную функцию (например, настройку чего-нибудь), без которой команды не могут выдать результат.

Получается, что на Вас всё завязано, и чем быстрее и качественнее будет работать Ваша команда, тем быстрее будут выдавать результат все остальные команды в компании.

И тут начинаются жалобы на медленную отработку запросов…

Естественно, в этой ситуации руководителю нужны фактические данные, а не слова.

На помощь приходит когортный анализ.

Привет, Хабр! Представляю вам перевод статьи «Get started with Google Go in Azure».

Microsoft предоставляет разработчикам Go набор Azure SDK для Visual Studio, Azure Stack и непосредственно Azure.

Для языка, предназначенного для программирования на системном уровне, язык Google Go (Golang) на удивление популярен. В его разработке принимали участие многие разработчики С, возможно поэтому он завоевал репутацию инструмента для разработки низкоуровневых систем, в том числе многих, используемых на Azure. Если вы запустили контейнер Docker, активировали любую услугу Azure Kubernetes или использовали Open Service Broker, вы используете код, написанный на Go.

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.

Talk — это расширение платформы Nextcloud, позволяет совершать защищенные аудио и видеозвонки, а также обмениваться текстовыми сообщениями через веб-интерфейс или мобильное приложение Nextcloud Talk. Для связи собеседников используется WebRTC, а для защиты передаваемой информации — end-to-end шифрование. Все компоненты Nextcloud Talk открыты.

Посты о Nextcloud на Хабре можно пересчитать по пальцам, и в них нет ни слова о Nextcloud Talk, поэтому я решил заполнить этот пробел. Под катом расскажу, как узнал о Nextcloud, Spreed.ME, Spreed и Talk, как тестировал Talk и с какими проблемами столкнулся при установке и настройке Talk.

Безопасность связана не только с теорией, но и с практикой. Поэтому мы открыли Школу информационной безопасности, которая будет посвящена в первую очередь практическим вопросам на основе опыта Яндекса. Сегодня мы расскажем читателям Хабра, чему именно мы будем учить в Школе.

Представьте себе системного администратора небольшой ИТ компании, например регионального провайдера. Это человек, который привык много делать руками, решать любые проблемы и даже отвечает за ИБ своей компании. Или есть разработчик, который несет ответственность за безопасность своего кода. Или человек в НИИ, которому приходится следить за локалкой и закрывать в ней дыры. Или просто студент-старшекурсник, а то и выпускник, интересующийся ИБ. У всех у них за плечами теория по безопасности из универа или книг, все они умеют самостоятельно учиться, но им живо не хватает систематизации знаний и практики именно в области ИБ. Такой практики, которая дает впоследствии уверенность в своих силах.

Как раз практические кейсы мы собираемся показывать и разбирать в новой школе Яндекса. Мы покажем на практике, как мы делаем безопасность в Яндексе, какие задачки подкидывает жизнь и как мы их решаем.

Программа и другие детали под катом. Еще под катом можно взять ссылку на тестовые задачи вступительного отбора, которые можно порешать и просто для развлечения.

IT-системы плотно вошли в нашу жизнь. Мощные и сложные программные продукты используются в самых разных сферах. При этом многие забывают, что появились IT-системы не просто так, как программные продукты, которые нужно продавать и внедрять, а как инструменты организации и автоматизации труда.

И очень важно помнить при выборе и внедрении IT-систем, что первичен здесь — труд, а не программное решение. Я не единожды сталкивался с тем, что люди выбирали программу просто потому что: “она понравилась”. В результате появляются попытки “натянуть” процессное производство, например, работу молокозавода, на ERP-систему, предназначенную для дискретного производства (сборка изделий).

В предыдущих материалах мы рассмотрели, что такое IdM, каковы признаки необходимости внедрения IdM, а также обозначили необходимость постановки целей и задач (т.е. — чего вы и бизнес хотите от системы управления доступом).

А ещё в предыдущей части мы отметили, насколько важно предложить бизнесу подготовленное и продуманное решение. Оно должно быть основано на исследовании проблемы, должно согласовываться с потребностями именно этого бизнеса, включать определённый подход к достижению поставленных целей и описывать уровень вовлечённости каждой из заинтересованных сторон.

Однако перед тем, как представить руководству готовый вариант (или несколько вариантов на выбор), следует понять, «на какой козе подъехать» к решению проблемы, выявленной при первичном аудите ситуации в компании.

13 февраля 2018 года вышла новая версия комплексного RMM-решения Panda Systems Management для централизованного и удаленного управления, контроля и обслуживания корпоративных сетей, устройств и ИТ-инфраструктуры. Представляем улучшения, реализованные в новой версии.

Прошел ровно месяц с тех пор, как наши брокеры подтвердили, что на таможне больше не требуют нотификации на электронику. Теперь мы видим, что посылки с гаджетами проходят, даже если раньше их содержимое считалось «запрещенкой». Но у нас до сих пор каждый день спрашивают, можем ли мы привезти тот или иной товар, который продается за рубежом. Постоянно приходится отвечать в соцсетях и в тикетах на сайте (мы, кстати, народ вполне понимаем – правила меняются так часто, что и не уследить). Попробуем разобрать вопрос тут. Так, чтобы было понятно, какие возможности теперь открылись, и зачем раньше ФСБ требовало информацию от производителей электронных устройств. Ну и хотим поделиться комичностью всей этой ситуации.

В своем блоге мы делаем основной акцент на публикации, посвященные интернету, работе операторов связи и всему связанному с этим. Однако в этом ворохе разнообразной информации мы совершили форменную глупость напрочь забыв о Цифровом телевидении, которое стало неотъемлемой частью деятельности операторов связи без которой провайдер уже не будет полноценным. В этом материале мы поговорим об основах организации IPTV, а в частности затронем основные методы доставки контента до потребителя.

Ни для кого не секрет, что бизнес непрерывно стремится к повышению своей конкурентоспособности. Кажется, что проще всего это сделать через инновации, давайте повысим эффективность одного-двух-трех бизнес-процессов с помощью современной, высокотехнологичной системы и будет нам счастье. Эта схема работает до тех пор, пока сложность нашей IT-системы не начинает работать против нас.



Вы знаете, насколько эффективно работают элементы вашей IT- инфраструктуры? Как они влияют друг на друга? Может быть, какой-нибудь элемент ухудшает работу системы в целом? Как понять, что это за элемент?