Итак, большое спасибо Алексею за участие в первом выпуске нового сезона “Открытое собеседование 2021-22”. Кстати, напомню, что все желающие могут принять участие в данном проекте – достаточно связаться со мной в том же LinkedIn – https://www.linkedin.com/in/iwalker2000/ – или в комментариях под видео – а подробнее о проекте смотрите в этом видео – https://youtu.be/h0hk03xX_Z0 – идея данных видео – дать всем ИТшникам, желающим развиваться в направлении администрирования Azure, представление о тех знаниях и навыках, которые потребуются для работы администратором Azure, а для тех, кто уже работает с Azure – проверить свои знания и навыки и быть уверенным в прохождении реальных собеседований на подобную позицию.
Так что смотрите и развивайтесь профессионально. Кстати, меня спрашивали, а что делать тем, кто уже гуру в “наземной инфраструктуре” – как им легче переходить в Azure, чтобы не начинать все с начала и не выглядеть “старыми джуниорами” – думаю, такие “публичные собеседования” очень помогут тоже определиться, а вообще – планирую записать отдельное видео с “мэппингом” локальных технологий в облачные технологии и куда “копать” с точки зрения миграции знаний, чтобы не начинать с нуля.
В этом видео Алексею “выпал” следующий набор вопросов (с которым он очень даже успешно справился, а вместе с темами идут и ссылки на мои доклады по данным темам):
Думаю, такой список тем, ответы на которые есть в интервью + ссылки на более подробные доклады – поможет вам подготовиться к участию в данной инициативе или к сдаче экзаменов.
Примеры записей предыдущего сезона смотрите здесь:
ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.01 – https://youtu.be/HmpgQoahXTA
ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.02 – https://youtu.be/cFzd62vlB9M
ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.03 – https://youtu.be/DECMirInQ2I
Хотите проверить свои знания по Azure? Понять, в каких разделах Azure у вас пробелы? Быть уверенными на собеседовании на новую позицию типа Azure Administrator/Engineer? Я запускаю на канале новый сезон инициативы “ОТКРЫТОЕ ИНТЕРВЬЮ” – к участию приглашаются все желающие. Шаринг виде – https://youtu.be/h0hk03xX_Z0 – приветствуется и добавляет +100500 в карму.
Обеспечить доступ ИТ-сообщества к оценке их профессиональных знаний и навыков для :
Пытаться понять индивидуальный уровень знаний в некоторых областях и найти «слепых пятна» в знаниях
Оценка перед сертификационными экзаменами
Имитация собеседований с реальными требованиями к реальной должности для подготовки к следующим карьерным ступеням
Предоставить интервьюируемому свою «карту знаний» и возможные способы дополнительного обучения, повышения уровня знаний (со ссылками на материалы).
Расширение знаний и навыков ИТ-сообщества путем обмена записанными сессиями «открытых интервью»
“ОТКРЫТОЕ ИНТЕРВЬЮ”– КАК?
«Открытое собеседование» представляет собой симуляцию реального 1–1,5-часового онлайн-собеседования (по Teams и т.п.), как типичное собеседование для какой-то «стандартной» ИТ-должности (для моего примера – L2 администратор службы поддержки Azure) с конкретными должностными обязанностями и требованиями (99 % близко к реальному)
«Открытое интервью» записывается и передается ИТ-сообществу любым подходящим способом.
Личность интервьюируемого может быть публичным или анонимным – по желанию интервьюируемого.
Главное условие – запись интервью будет опубликована вне зависимости от результатов и желания собеседника.
Собеседник не знает вопросов, только общие темы – например, ему задают только требования к должности (поскольку это имитация собеседования).
После самого собеседования – карта слепых пятен и личный путь обучения, ссылки, материалы будут предоставлены интервьюируемому (не для протокола, вне записи).
ИТАК, каждый желающий проверить свои знания по администрированию Azure путем прохождения “симуляции” реального собеседования на реальную должность инженера/администратора Azure уровня L2 – может связаться со мной по указанным выше профилям – в LinkedIn или YouTube – и мы договоримся об удобном времени такого “собеседования”.
Описание такой позиции Azure L2 Support Engineer (реальной) и требований к ней (также абсолютно реальные) – смотрите ниже. Все вопросы в “интервью” также взяты из реальных задач, с которыми приходится сталкиваться администратору Azure в ежедневной работе.
Job responsibilities
Work with presales Architects team and customer technical team to build LLD
Support customer migration project
Build ARM, DSC, Security policies based on customer requirements and reference architecture
Deploy Azure IaaS/PaaS solution.
Implement Automation, Monitoring, DR solutions in Azure.
Continuous delivery infrastructure for managed customers as Infrastructure as Code.
Disaster Recovery.
Create new Automation solutions in respond to customer/L1/business requests.
Handover and train L1 team.
Required skills and experience
Knowledge in the recommended best practices and architectures of Azure — for example, Azure Virtual Datacenter — and the ability to tailor customer solutions to architecture and security requirements (IaaS/PaaS, O365).
Knowledge in networks concepts in Azure – VNET, VPN Gateways, ExpressRoute, Application Gateway/WAF, Firewall, Traffic Manager, Azure Front Door and hands on experience on planning, deploying and managing Azure Networks and Hybrid connectivity.
Knowledge in security concepts in Azure – Azure AD, IAM, VM / VNet hardening – and their practical application in the development of user infrastructures (IaaS/PaaS, O365) in Azure.
Practical knowledge and hands-on experience and skills in using Azure deployment tools – ARM template, az / PowerShell / DSC – and IaC concepts/processes. Scripting skills (powershell/DSC/cmd) for deploying IaaS and OS in virtual machines.
Practical knowledge, hands-on experience and skills in working with monitoring and support tools in Azure – ASC, AM, ASR, Automation. Skills and experience in developing scripts for Azure Automation runbooks.
Hands-on experience in the administration, support and resolution of problems in the Windows Server / Linux OS and practical experience in managing them using remote PowerShell.
Additional skills, knowledge and experience related to Azure or on-premises technologies are the big plus
Administer Azure AD / Active Directory on-prem
Windows Admin Center / Hybrid Infrastructure
Administer Office 365 / Exchange / SharePoint Server etc. office servers on-prem
DBA – Azure SQL / SQL Server etc. on-prem
MDM / MAM / Windows 10 using Intune / SCCM
Chef, Puppet, Ansible
Примеры записей предыдущего сезона смотрите здесь:
ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.01 – https://youtu.be/HmpgQoahXTA
ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.02 – https://youtu.be/cFzd62vlB9M
ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.03 – https://youtu.be/DECMirInQ2I
Продолжаю тему «цифровой трансформации» в отношении к современным облачным Managed Services, которую я, пользуясь личным практическим опытом, частично осветил в первой части данной статьи. Напомню, там речь шла о концептуальных и стратегических отличиях новых облачных Managed Services от традиционных «динозавров» Managed Services, вкратце:
Поставщики облачных Managed Services выступают «головой», а не «руками» заказчика и концентрируются не на том, «чтобы все виртуальные машины работали», а на консультационной помощи заказчику по миграции в облака и модернизации приложений в формат «нативных» решений. Фактически, поставщик современных облачных Managed Services для заказчика – это, как модно говорить сейчас, «Trusted Advisor» по всему, что касается облаков.
Облачные Managed Services отвечают за SLA бизнес-процессов, а не за непонятный для бизнеса заказчика SLA времени ответа на запрос. Задача современных Managed Services обеспечить желаемый SLA для критического сервиса/приложения заказчика, используя все доступные средства облака и способствовать модернизации приложений.
Поставщик современных облачных Managed Services работает с заказчиком по принципу «непрерывного проекта миграции и модернизации», обеспечивая постоянное внедрение новых служб, решений и модернизацию существующих без переключения на «сторонние проекты».
Поставщик современных облачных Managed Services работает в непрерывном контакте с заказчиком, имея в команде технического менеджера, который поддерживает регулярную коммуникацию с заказчиком, знает о всех его планах и проблемах, обеспечивает координацию с различными командами и вендорами заказчика и управляет ресурсами своей команды и текущими проектами.
И, наконец, «цена вопроса» за услуги Managed Services, которая формируется не путем подсчета «виртуальных машин по головам», а в проценте от общей суммы утилизации Azure клиентом.
А в этой части мы поговорим о технологических и процедурных отличиях современных облачных поставщиков Managed Services по сравнению c «динозаврами» «традиционных» Managed Services.
В предыдущем посте я уже писал, что облака вообще и Azure в частности «добавляют новый, не достижимый ранее, уровень гибкости для Managed Services благодаря своим сервисам уведомлений, мониторинга, автоматизации, автоматического поддержания здоровья и безопасности поверх таких возможностей облаков, как эластичность, масштабируемость и отказоустойчивость». И ключевое слово тут – «совершенно новый уровень мониторинга и автоматизации».
Такой мониторинг и автоматизация в первую очередь должны быть направлены на обеспечение требуемого SLA для критических бизнес-сервисов и приложений заказчика, о котором говорилось в предыдущей части. И, учитывая специфику и возможности мониторинга в Azure и сервиса Azure Log Analytics – основной отличительной чертой современного провайдера Azure Managed Services является проактивный мониторинг с предсказанием тенденций по тем или иным показателям критических приложений и/или поиском аномалий в текущих показателях. Звучит красиво и непонятно, а в реальности – Azure Alert, который базируется на нескольких командах в запросе KUSTO к нужным данным, которые хранятся в таблицах Azure Log Analytics – и мы получаем, например, тенденцию уменьшения свободного места на диске исходя из показателей мониторинга последних 15-30 минут, часов, дней – в зависимости от того, насколько высоки требования к SLA решения и как «чутко» нам нужно реагировать на возможное отсутствие дискового пространства для серверов приложений и сколько за это готов платить заказчик. Напомню, что каждый такой Alert с запросом и собственно, время работы вызванной после процедуры Azure Automation стоит денег, пускай это идут центы, но при активном использовании с минутными интервалами – может набегать ощутимая сумма.
Сценарии применения такой «предсказательной» автоматизации – бесконечно обширны благодаря инструментарию управления в Azure. Конкретный пример с предсказанием окончания места на диске за несколько дней до критического значения (обычно 5-10%) в реальных инфраструктурах – это и оправка уведомлений всем заинтересованным лицам + создание «тикета» в системе управления того бизнес-приложения, у компонентов которого место на диске подходит к концу, и запуск Azure Automation runbook, который в ближайшее окно обслуживания остановит, если возможно, проблемную виртуальную машину и увеличит размер диска на ней. Другой сценарий – это предсказание изменения нагрузок (кол-ва запросов) на том же Azure Application Gateway, чтобы предварительно увеличивать/уменьшать количество работающих экземпляров App Gateway в зависимости от недельных/сезонных и общих тенденций, что позволяет обеспечивать и высокую доступность решения, и экономить деньги клиента, подстраивая количество экземпляров под реальные потребности. И да, я в курсе про autoscaling для App Gateway, но как показывает опыт – всегда стоит держать +1 экземпляр в горячем режиме про запас – потому что автоматическое масштабирование не успевает реагировать на те же атаки или даже просто резкий скачек нагрузки при каких-то онлайн событиях. А вот такие онлайн события по расписанию очень легко предсказывать на недельном форекасте и реагировать за 15-30 минут до их начала расширением пула и экземпляров App Gateway, и App Services, и SQL Database DTU, и прочих компонент приложения.
Интересной особенностью Azure Monitor и Azure Log Analytics является Azure VM Insights – возможность «заглядывать» в то, что происходит на уровне ядра OS виртуальных машин и получать информацию не только о показателях производительности базовых компонентов, но и, например (еще один реальный сценарий), мониторить и предсказывать «всплески» высокого уровня задержек сетевых соединений (outbound connection latency) процессов приложения при запросах между виртуальными машинами, на которых находятся компоненты приложения, или к базам данных. Опять же, зная суточные/недельные/месячные тенденции и текущие показатели – очень легко предсказывать возможные «залипания» соединений и быстро реагировать на проблемы путем увеличения количества виртуальных машин требуемого типа в пуле приложения. И да, заметьте, тут для масштабирования используются не стандартные показатели типа CPU/RAM/Disk или даже число запросов, а именно тот показатель, который может серьезно влиять на доступность и производительность приложения, не смотря на отсутствие явных признаков высокой утилизации конкретной виртуальной машины и всего решения в целом.
И чтобы не быть голословным (все-таки техническая часть) – вот вам небольшой пример того самого запроса KUSTO к Azure Log Analytics с визуальным предсказанием нагрузки App GW, который отображает общую почасовую тенденцию изменения трафика на App GW в следующие 3 дня исходя из истории предыдущих 5 дней:
let min_t = toscalar ( AzureDiagnostics | where TimeGenerated > ago(5d) | summarize min(TimeGenerated));
let max_t = toscalar ( AzureDiagnostics | where TimeGenerated > ago(5d) | summarize max(TimeGenerated));
AzureDiagnostics
| where TimeGenerated > ago(5d) and ResourceType == “APPLICATIONGATEWAYS” and OperationName == “ApplicationGatewayAccess”
| make-series Requests_H = count() on TimeGenerated from min_t to max_t+3d step 1h
Визуальный результат будет выглядеть так, где синий график – текущие показатели количества запросов к сайту за прошедшие 5 дней, а красный график – предсказание тенденций изменения трафика на следующие 3 дня:
А дальше – выполняя такие запросы по расписанию (и помним о цене запроса) и оценивая тенденции или находя аномалии – запускаем в случае критических показателей требуемые скрипты Azure Automation или других продуктов, которые внедрены в процессы компании.
Проактивный мониторинг инфраструктуры – это отличное средство обеспечения требуемых SLA, но не стоит игнорировать и стандартные средства эффективной реакции на проблемы инфраструктуры и приложений в Azure, такие, как уведомления/предупреждения о проблемах (служба Azure Alerts, являющаяся частью Azure Monitor) и автоматической проверки здоровья (Health checks/auto-healing, опции различных служб), работающие в той же связке с Azure Automation для реакции на события путем запуска требуемых Azure Automation Runbook.
На рынке существует достаточно большое количество решений, обеспечивающих сбор и мониторинг данных по работающей инфраструктуре в Azure, но в большинстве своем – это универсальные системы, строящие «красивые отчеты» и «дашбоарды» для различных компонентов, в то время, как для современных облачных Managed Services важно гарантировать SLA клиентского сервиса в целом, что уже упоминалось в первой части статьи. Потому для доведения решения до требуемой кондиции – контроля за SLA и реакции на возможные проблемы – все равно требуется доводка таких универсальных систем «напильником». И, как показал опыт – подстраивать сторонние готовые универсальные мониторинга системы под задачи конкретного заказчика – весьма утомительно и, часто, очень проблематично ввиду особенностей архитектуры этих систем. Кстати, об архитектуре систем – практически эта архитектура требует в тенанте (даже не подписке) заказчика наличия учетных записей с такими правами, на которые служба безопасности заказчика категорически не согласна. Так что приходится все это решать средствами собственных скриптов, объединяя с упомянутыми выше очень даже функциональными сервисами Azure. Как работает такая связка – я постарался вкратце рассказать в ходе недавнего онлайн семинара по Azure Automation и Azure Monitor/Log Analytics – https://youtu.be/a6VGeDUNYt4
Таким образом, современные Azure Managed Services базируются на обширном репозитории шаблонов скриптов и запросов, которые можно быстро адаптировать под потребности конкретного заказчика и задача команды современных облачных Managed Services – активно расширять и оптимизировать данный репозитарий.
Интересным аспектом является модный ныне DevOps, о котором столько разговоров. И да, вы правильно сделали выводы – если я не начал с самого начала нахваливать DevOps – он действительно не играет существенной роли в предоставлении Managed Services (если, конечно, вы не предоставляете DevOps, как одну из услуг Managed Services). Тот же практический опыт показал полное отсутствие каких-либо преимуществ применения DevOps перед традиционными средствами развертывания и управления инфраструктурой в Azure – типа шаблонов ARM, Azure Automation, DSC – для предоставления тех же услуг развертывания инфраструктуры в рамках Azure Managed Services. Почему так? – Да потому, что большинство инфраструктур заказчика стабильны и меняются не так часто, потому репозитория ARM шаблонов вполне достаточно и для начального развертывания, и для дальнейшей модификации/восстановления при сбоях. Что же касается программной части – тех же Azure Apps Services, Azure Data Platform, Kubernetes и прочих – в задачу Azure Managed Services входит их мониторинг и поддержка, а начальное «запиливание» кода в большинстве случаев – это ответственность команд разработчиков (причем, чаще – во множественном числе), которые работают над своим продуктом и со стороны поставщика Azure Managed Services им требуется готовая инфраструктура самой службы DevOps, настроенные системы мониторинга и реакции на проблемы со стороны Azure. Очень часто – разработчики вообще не представляют, какие функции управления инфраструктурой того, что они «наворотили», имеются в Azure и именно «обвес» мониторинга и высокой доступности всего решения в целом – куда входят и Application Gateway/WAF с CDN, и App Services с базами данных и хранилищами, и средства управления масштабированием и здоровьем, и репликации, а не отдельный экземпляр App Services – и является зоной ответственности команды Azure Managed Services и требует постоянного взаимодействия с командой разработчиков и разработки спецификаций, которые позволяют упростить процесс работы такой инфраструктуры и которым должны следовать разработчики в архитектуре своего решения.
Так что DevOps – это скорее нет, чем да… Или вы «подхватываете» у заказчика, а вернее – его поставщиков – функции разработки и DevOps по совместительству. Но это уже совсем не та история, которая про Azure Managed Services.
А вот следующая часть «той истории» современного облачного поставщика Azure Managed Services начинается в последних предложениях про DevOps о спецификациях – это называется Operational Excellence (OE) – по-русски звучит коряво – «Операционное Совершенствование» – потому буду использовать в тексте аббревиатуру OE. Operational Excellence я бы назвал одной из основных составляющих успеха после того, как вы наработали у себя в облачных Managed Services необходимый минимум репозитория шаблонов скриптов и дальше развиваете свой бизнес. Какие первоочередные задачи стоят перед OE в данном случае? Во-первых – это работа над спецификациями типа LLD benchmark checklist, Developers benchmark checklist и т.п. Все эти спецификации должны определять списки требования к архитектурам, которые планируют для ваших заказчиков либо ваши коллеги из Professional Services, либо разработчики заказчика, либо непосредственно ваши сотрудники, работающие в Managed Services. Такие OE спецификации для планирования решения чаще всего содержат в себе требования к наличию различных компонентов мониторинга и управления в дизайне по умолчанию. Например, для Azure LLD OE benchmark checklist это проверка архитектуры на:
· Наличие Azure Monitor Alert, который уведомляет о глобальных проблемах всех служб Azure
· Наличие Alert для критических значений вместимости и производительности для всех компонентов
· Наличие требуемых служб мониторинга – Azure VM Insights, Application Insights, Azure Log Analytics, Azure Security Center для критических компонентов
· Наличие карты требуемых процессов обслуживания
· Наличие автоматизации рутинных процессов с использованием Azure Automation
· Наличие карты зависимостей критических приложений, для которых будет требоваться SLA
· Наличие плана восстановления после сбоев
· Наличие списка других объектов/процедур, которые являются критическими в инфраструктуре и т.п.
Следующая часть OE – это внутренние процессы, такие, как контроль за процедурными документами и их соответствию текущему статусу инфраструктуры, улучшение основных процессов поддержки SLA путем внедрения результатов анализа каждого сбоя – Root Cause Analysis (RCA), и, самое главное – это наличие процессов анализа обращений клиентов с целью обнаружения типовых обращений и создания на их основе новых автоматических процедур или решений, которые обеспечивают доступ к требуемой информации/операций посредством порталов или приложений самообслуживания.
И да, Operational Excellence – это моя «боль», поскольку даже при очень хорошо продуманных процедурах, особенно внутренних – надо еще научить коллектив соблюдать эти процедуры. И здесь, опять же – приходит на помощь и автоматизация бизнес-процессов, и, конечно же, правильные KPI. Но это уже тема следующей части про действительно современные и актуальные облачные Managed Services.
Зато есть еще одна, упомянутая выше, технологическая часть Azure Managed Services, которая существенно отличается от «традиционных» – поскольку мы работаем с облаками и, как уже говорилось в первой части, не блокируем полностью клиентский доступ к инфраструктуре – тут у нас открывается обширное поле деятельности для создание решений по самообслуживанию, особенно, если OE работает и вы быстро определяете базовые рутинные потребности в обслуживании для каждого клиента Azure Managed Services. Что дальше? Безусловно – автоматизация или применение современного удобного инструментария/платформ разработки решений, которые позволяют максимально ускорить взаимодействие заказчика с его же инфраструктурой.
К чему это я? Все очень просто – такими инструментами и платформой для создания решений самообслуживания являются и сам Azure с его Log Analytics, Logic Apps, Automation, Functions, Cognitive Services, и платформа Power Platform c Power Apps, Power Virtual Agents. Применение Power Apps позволяет очень легко и просто предоставить заказчику, особенно менеджменту, простое приложение-панель информации для мобильных платформ (телефонов и планшетов) – наиболее востребованная, как показывает опыт и анализ запросов, функциональность – «хотим видеть на телефоне прямо в реальном времени состояние всех приложений и их компонентов (светофорчики)». Используя Power Apps и средства типа Log Analytics и Functions, которые вызываются из Power Apps – создание такого приложения занимает считанные дни, модификация – часы, а публикация – минуты. При этом такое простое приложение имеет громадный позитивный эффект на лояльность и удовлетворенность менеджмента заказчика предоставляемыми Azure Managed Services.
Второй сценарий – это автоматизация стандартных технических запросов от инженеров заказчика, которые обслуживают непосредственно приложения, обычно – внутри виртуальных машин и лезть куда-то в незнакомый портал и отвечать за «поломанное» им совершенно не интересно. Опять же, как показала практика – самый эффективный способ быстрой реакции на запрос – это автоматизация обработки почтовых сообщений, в которых с простым синтаксисом описываются требуемые операции, такие, как создание виртуальных машин или команды к существующим, изменение конфигураций NSG, App Services, Application Gateway, запросы на отчеты и многое другое. А далее – используется Azure Logic Apps, которые управляют данным процессом, с запросом (если требуется) подтверждений операций как со стороны ИТ заказчика, так и инженера поддержки команды Azure Managed Services. И после прохождения всех формальностей – такое электронное письмо разбирается через Cognitive Services, проверяется на предсказание возможных последствий или наличие аномалий для SLA и сами операции выполняются средствами Azure Automation, Functions и Log Analytics. Подобные сценарии я рассматривал в упомянутом ранее видео про автоматизацию управления Azure – https://youtu.be/a6VGeDUNYt4
Опять же, как и в варианте с Power Apps, на разработку бизнес-процесса требуется несколько дней, после чего уже технические специалисты заказчика остаются очень довольными простотой взаимодействия. Сразу скажу, что особым хитом сезона являются всякие там запросы на отчеты по email – написал имя виртуальной машины или ресурсной группы и даты – и получил через минуту полный почасовой отчет утилизации ресурсов ВМ.
И тут возникает правильный вопрос – а как же Level 1 Support? А вот никак, поскольку в большинстве своем Azure Managed Services – это непрекращающийся постоянный процесс модернизации инфраструктуры из наследованных технологий в облачные. И если специалист L1 не в курсе процессов и зависимостей внутри инфраструктуры заказчика – он скорее не поможет, а навредит, и при этом – базовые операции типа пресловутой «перезагрузить ВМ» уже запросто могут быть делегированы системе со службой самообслуживания, поскольку вызывая такую операцию из приложения или почты – заказчик вызывает не команду перезагрузки ВМ, а достаточно сложный скрипт, проверяющий влияние такой операции на SLA бизнес-приложений и принимающий решение уже на базе сценариев «лучшего возможного SLA».
А Level 1 – разве что приятный женский голос, отвечающий по телефону + мы начали эксперименты с Power Virtual Agents для предоставления той же информации о статусе и отчетов. А «мальчикам» из Level 1 придется либо расти до инженеров (про требования к инженеру в Azure у меня есть серия публичных собеседований – см.ниже), либо искать другую работу.
· ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.01 – https://youtu.be/HmpgQoahXTA
· ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.02 – https://youtu.be/cFzd62vlB9M
· ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.03 – https://youtu.be/DECMirInQ2I
И вот про то, как изменяется орг.структура организации, которая решила перейти от предоставления «традиционных» Managed Services к современным облачным Managed Services – будет третья часть данной статьи.
Как показывает личный опыт последних лет, красивые слова типа «диджитализация», «цифровая трансформация» и прочие расхожие фразы, которые должны подчеркнуть невероятную «продвинутость» компании на пути к новым вершинам «облачного» бизнеса – очень часто являются всего лишь красивой вывеской, за которой скрывается уровень бизнеса 20летней давности и косность менеджмента, по прошествии «20 лет успеха» не способного уже мыслить по другому, как раз критериями той самой «цифровой трансформации»… Нет, эта статья не будет про различные личные психологические практики «как принимать новое» и «читать больше и думать инновационно» – эта статья будет более практической – я постараюсь сформулировать собственное видение того, что является действительно «трансформированными» Managed Services для облака (в моем случае речь пойдет про Azure и базируется на личном опыте создания и руководства соответствующем департаментом) в отличие от «традиционных» Managed Services, к которым продолжают тяготеть «динозавры» бизнеса под вывеской «диджитализации».
Итак, чем же должны отличаться организации, которые предоставляют современные Azure Managed Services от организаций с «традиционными» Managed Services и какой путь должны пройти последние, чтобы предоставлять действительно современные Managed Services для облаков, а не уровень звонка в Level 1 типа «у нас не работает виртуалка – пожалуйста, перегрузите»?
Облака – это существенное изменение в управлении, поскольку они добавляют новый, не достижимый ранее, уровень гибкости для Managed Services благодаря своим сервисам уведомлений, мониторинга, автоматизации, автоматического поддержания здоровья и безопасности поверх таких возможностей облаков, как эластичность, масштабируемость и отказоустойчивость. Соответственно, клиенты Azure Managed Services ожидают от поставщика услуги, что все данные инструменты будут использованы для обеспечения беспрерывной работы уже не отдельных виртуальных машин, а их бизнес-сервисов и бизнес-процессов в целом и разговор «ой, у меня не работает виртуальная машина» просто не может произойти в рамках облачных Managed Services. Также клиенты ожидают от поставщиков Azure Managed Services, что их методологии и подходы к Operational Excellence тоже будут трансформированы и адаптированы к облачным условиям, где используются не только реактивные инструменты мониторинга и автоматизации здоровья решений и SLA, но и службы автоматического улучшения инфраструктуры бизнес-сервиса, исходя из возможностей аналитики, поиска аномалий и предсказаний средствами облачных сервисов типа Log Analytics или Sentinel. И, безусловно – клиенты ждут помощи в миграции в облако и дальнейшей адаптации их традиционных «наземных» решений – этот аспект даже не обсуждается – и если непосредственно миграция уже проведена – чаще всего это вариант с миграцией существующих «наземных» сервисов в виде виртуальных машин IaaS Azure – клиенты ожидают от поставщика Azure Managed Services дальнейших шагов по трансформации такой инфраструктуры в нативные сервисы Azure.
И здесь первая огромная разница между традиционными и облачными Managed Services – заказчик видит в поставщике Azure Managed Services не просто «аутсорсовые руки», которые он будет использовать для выполнения рутинных операций типа «перегрузить виртуальную машину», а именно доверенное лицо, которое в первую очередь предоставляет экспертизу по «движению в облако», причем заказчик ожидает, что получит возможность общения с высококлассным SME (Subject-Matter Expert) по всему возможному спектру сервисов Azure, который обозначен в контракте, и общение между заказчиком и поставщиком услуг будет проходить в стиле знаменитого диалога:
— Теперь вот такое предложение: а что, если — Не стоит. — Ясно Тогда, может быть, нужно — Не нужно. — Понятно. Разрешите хотя бы — А вот это попробуйте.
Пожалуй, повторюсь по поводу этого пункта, поскольку до многих руководителей «традиционных» Managed Services этот момент доходит, как до того диплодока с очень длинной шеей – в случае с публичным облаком типа Azure заказчик самостоятельно может выполнять большое количество базовых операций – благо, Azure существенно упрощает многие административные рутинные функции и предоставляет отличный инструментарий управления – будь то портал Azure или Azure PowerShell сотоварищи – и это не те местечковые «облака» с банальными виртуальными машинами, которые расплодились за последние 10-15 лет и так и не превратившиеся в настоящие облака, и которые не в состоянии предоставить нормальный инструментарий управления для клиентов и потом все «пляски с бубнами» вокруг каждой виртуальной машины должны выполняться исключительно персоналом провайдера Managed Services. В случае Azure заказчик не нуждается в столь плотной «опеке» и «залоченной» облачной инфраструктуре, к которой имеют доступ только сотрудники поставщика «традиционных» Managed Services – фактически, это создает промежуточное звено во внедрении решений и существенно замедляет процессы – что полностью противоречит задачам облаков – ускорению бизнеса путем быстрой адаптации и развертывания ИТ сервисов. Но Azure продолжает быть достаточно сложным для инженеров заказчика, в ответственность которых входят именно бизнес-сервисы, а не то, как их работа обеспечивается в Azure – потому именно экспертные услуги со стороны поставщика Azure Managed Services и являются главной отличительной чертой «нового» провайдера современных облачных Managed Services.
Вторая отличительная черта поставщика Azure Managed Services – это SLA. Нет, не тот SLA, о котором любят писать провайдеры Managed Services в контрактах – про гарантированное время ответа и восстановления, это в реальности мало кого интересует в облачных сервисах – облако Azure куда стабильнее всех этих «местечковых облачков» – а действительный доказанный SLA конкретных бизнес-сервисов. Именно так – заказчик дает запросы на предоставление требуемого уровня SLA для своих критических сервисов, а поставщик Managed Services – их обеспечивает. И здесь уже в дело вступает первый пункт – поcтавщик услуг Azure Managed Services предоставляет не «руки», а «головы», в задачу которых входит в том числе и совершенствование инфраструктуры заказчика (в рамках контракта Managed Services) для достижения необходимого уровня SLA конкретного критического бизнес-сервиса. Дальше уже исключительно техническая и финансовая часть задачи по достижению требуемого SLA – возможно ли такое технически в рамках Azure и конкретного бизнес-приложения заказчика и готов ли заказчик платить за все «хотелки» для достижения такого SLA. А поскольку в рамках Azure можно «наворотить» многое для достижения требуемой высокой доступности, надежности, защиты от сбоев и восстановления конкретного решения – то задача вполне решаемая для «настоящих» специалистов поддержки (а не L1, который «должен перегрузить ВМ») без особых проблем. Но самое интересное в данном случае с SLA – если само «наследованное» приложение не адаптировано к работе со средствами масштабирования и высокой надежности в Azure и требуется модификация или даже тотальное изменение архитектуры решения. И тут вступает в дело третья, и, по большому счету – самая важная – отличительная черта современного облачного поставщика Managed Services в отличие от «традиционных» Managed Services.
Итак, отличие третье – основные работы современные облачные провайдеры Managed Services выполняют для заказчиков не в рамках «тикетов» на «перегрузку ВМ» или «изменение размера ВМ», а в рамках постоянной адаптации и оптимизации клиентских сервисов в облаке. Рассматривайте это, как продолжительный непрекращающийся разбитый на фазы проект модернизации, внедрения новых компонентов, оптимизации существующих и т.п. Никаких устаревших бизнес-моделей, где в контракте оговорено количество виртуальных машин, сетей и прочего для обслуживания, а все новое – это отдельный «проект по планированию и развертыванию», который выполняют «Professional Services». В случае облачных Azure Managed Services все развитие инфраструктуры в облаке, возможно, с планами на год или даже несколько лет – это задачи и ответственность команды Azure Managed Services. Выглядит очень требовательно? Возможно, но речь не идет о «переписывании» приложений (хотя такие сервисы и предлагаются некоторыми поставщиками услуг облачных Managed Services), а о консультационной работе с разработчиками заказчика и рекомендациях по изменении кода приложения или архитектуры согласно лучшим практикам Microsoft для Azure. Фактически, специалисты из команды Azure Managed Services выступают и постановщиками задачи для разработчиков (совместно с заказчиком) и SME по архитектуре решения, поскольку одна из зон ответственности провайдера Azure Managed Services – это SLA приложений и сервисов и их архитектура должна быть спланирована под задачи соответствия договоренному SLA. А что насчет планирования и внедрения новых сервисов в облаке для заказчика – и это тоже работа команды Azure Managed Services. Во-первых, потому, что любая облачная инфраструктура – это в первую очередь следование лучшим практикам и они говорят о построении решений типа виртуального ЦОД с архитектурой HUB-SPOKE и после построения центрального хаба все дополнительные сервисы подключаются по типовым проектам, как spoke – и «городить» там что-то серьезное, с привлечением «Professional Services», вообще не требуется. А во-вторых – именно команда Managed Services обладает полной актуальной информацией по всей инфраструктуре клиента, возможных дополнительных ограничениях или требованиях, планах по развертыванию других сервисов и многой другой информацией – потому, фактически, проект подобных улучшений или будет связан с длительным процессом передачи знаний между командой Managed Services и командой «архитекторов» Professional Services c последующими согласованиями результатов и т.п. – что делает такой проект существенно громоздким и дорогостоящим, или может быть выполнен командой Managed Services с привлечением необходимых SME по каким-то специфическим решениям как раз из команды Professional Services. Хотя, как показывает опыт работы – инженер L2 Azure Managed Services после года активной работы в среде крупного корпоративного заказчика даст большую фору «архитектору» Professional Services по планированию и внедрению решений в обслуживаемой среде – поскольку имеет практический опыт и куда более глубокое понимание конкретной среды – так что в реальности, по личному опыту – привлечение SME от «Professional Services» вообще не требовалось – все планирование и внедрение новых решений и модернизация существующих для соответствия SLA выполнялись только силами L2 инженеров и L3 архитекторов Azure Managed Services, без привлечения сторонних «экспертов».
И здесь в дело вступает еще одно отличие – для нормального взаимодействия с клиентом требуется постоянный технический диалог, в рамках которого обсуждаются планы и проекты, а клиент может обратиться с соответствующими техническими вопросами типа «А нельзя ли сделать так?» к тому самому SME по Azure, который имеет полное представление об инфраструктуре клиента. И такой диалог должен быть постоянным, регулярным и проактивным со стороны поставщика Azure Managed Services, т.е. – команда Azure Managed Services, которая работает с конкретным заказчиком, должна иметь в своем составе кого-то, кто будет выполнять функции условного «Technical Account Manager» (TAM) для клиента. Практика показывает, что именно L3 support Azure Architect прекрасно справляется с регулярными техническими коммуникациями с заказчиками и является для них тем самым основным SME по Azure, единой точкой контакта по всем техническим вопросам и принимает участие во всех встречах/совещаниях по планированию и развитию инфраструктуры, и, конечно же – лидером команды Azure Managed Services для конкретного заказчика. Данный условный TAM должен обладать полным знанием об инфраструктуре заказчика, быть в курсе планов развития инфраструктуры, выделять и планировать ресурсы команды под будущие проекты и вести текущие проекты с точки зрения технической экспертизы и управления. И, опять же – как показывает практика – от персоналии такого вот TAM во многом зависит успешность работы с конкретным заказчиком, его удовлетворенность сервисом и многое другое. Так что регулярные созвоны пару раз в неделю и работы на опережение (все эти Operational Excellence – про это – в следующей части) очень даже требуется со стороны TAM.
Еще одним различием облачных Managed Services и «традиционных» является «цена вопроса» – переход от «подсчета по головам», т.е. по количеству обслуживаемых виртуальных машин с фиксированной ценой за одну ВМ, к проценту от цены утилизации в облаке. Согласитесь, считать стоимость облачных сервисов по «головам» ВМ, в то время, как одна из задач современных Azure Managed Services – оптимизация инфраструктуры, обеспечение SLA для бизнес-сервисов и приложений – требует модернизации «зашитых» в ВМ приложений в IaaS окружении в сервисы PaaS и что автоматически удаляет ВМ в будущем – крайне странно. Плюс в Azure масса сервисов, которые требуют управления и которые не посчитаешь «по головам». Потому – только процент от утилизации. Опять же – в зависимости от набора предоставляемых в рамках Managed Services услуг процент может варьироваться от 10% до 30% стоимости самих утилизированных ресурсов Azure. Это, ко всему прочему, двигает заказчика более пристально относиться к вопросам стоимости и оптимизации инфраструктуры (что упрощает и внедрение SLA бизнес-сервисов для команды Managed Services), а с другой стороны – Managed Services заинтересована в постоянном развитии инфраструктуры и драйвинге процессов миграции других сервисов заказчика из локальной инфраструктуры в облако. И показатель роста утилизации (и, соответственно, роста стоимости услуг Azure Managed Services) – отличный KPI для новой облачной команды (наряду с обновленным KPI по SLA – только не того, который представляет «непонятные тикеты» ответа, а SLA бизнес-приложений заказчика).
И вот про KPI и прочие шаги, которые надо предпринять провайдеру услуг (типа реализации облачного варианта Operational Excellence) для трансформации «традиционного залоченного» Managed Services в современный облачный/Azure Managed Services – мы поговорим в следующей статье на эту тему.
Продолжение – следует…
интересная серия видео, на которые рекомендую обратить внимание – это “открытое собеседование” на позицию Azure L2 support engineer (попросту “администратор Azure”) – которое поможет вам сориентироваться в требованиях к позиции и оценить свои знания:
* ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.01 – https://youtu.be/HmpgQoahXTA
* ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.02 – https://youtu.be/cFzd62vlB9M
* ИТ-карьера – Azure L2 support engineer – публичное собеседование на позицию, что нужно знать – ч.03 – https://youtu.be/DECMirInQ2I
Особенно «возбудились» почему-то некоторые «патриотические» деятели с дежурной фразой – «ты не живешь в Украине, какое право ты имеешь об этом писать!» – спасибо, повеселили, значит, мой «толстый» троллинг зацепил за живое…
Ладно, оставим лирику – все равно я всякое разное в ФБ комментах покилял, а самых ярых – заблокировал.
А мы посмотрим пошагово, чего же такого «провтыкали» CIO, что могло бы предотвратить эпидемию в украинских компаниях «на корню», что есть в базовых рекомендациях Defense-in-Depth https://msdn.microsoft.com/en-us/library/cc767969.aspx и реализовать которые не является большой проблемой. Напомню, требования Defense-in-Depth (DiD) достаточно простые и предусматривают реализацию тех или иных сервисов защиты на всех уровнях ИТ-инфраструктуры.
Уровень
Технологии
Данных
ACL/шифрование/классификация данных с RMS
Приложений
SDL, антивирусы, «бронирование» приложений и сервисов, App/Device Guard
Хостов
«Бронирование» ОС, аутентификация, управление обновлениями, FW, защита от вторжения (IDS), VBS, Device Guard
LAN
Сегментирование и изоляция (VLAN), шифрование (IPSec), защита от вторжения (NIDS)
Периметр
FW, контроль доступа, App FW, NAP
Физическая безопасность
Охрана, ограничение доступа, аппаратный контроль и аудит доступа, отслеживание устройств, камеры наблюдения
Люди, политики, процедуры
Документирование, тренинги, предупреждения и уведомления, наказания…
Есть и более «продвинутые» методы защиты, которые обеспечивают высокий уровень защиты от современных типов атак, которые в том числе, использовались и в Petya – Securing Privileged Access – http://aka.ms/privsec
Итак, начнем с первичного заражения. В данной эпидемии рассматривается 2 основных сценария – проникновение через почтовые сообщения в виде вложения к письму и через систему обновлений MEDoc, так называемую атаку «software supply chain attacks», когда взламывается поставщик ПО. Подробно, кто еще не прочитал – «разбор полетов» можете посмотреть здесь – https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/
При этом в первом сценарии запущенный пользователем из почты исполнимый файл атакует ОС через уязвимости SMBv1 (EternalBlue/EternalRomance) и получает все требуемые права, чтобы выполнить свои процессы – шифрование и распространение.
Какие методы противодействия Defense-in-Depth помогут от подобной атаки:
Периметр – сервис фильтрации почтовых сообщений (например, в Microsoft Exchange) – просто удаляющий все файлы, кроме разрешенных типов, антивирусная система для электронной почты, если нет чего-то подобного – аренда аналогичных облачных сервисов, например – Exchange Online Protection, «знания» которого не зависят от «расторопности» админов (время внедрения – 30 мин + обновление доменного имени).
Приложения – антивирусы, которые ловили Petya.A с самого начала эпидемии. Надо обновлять сигнатуры – нет, не слышали?
Хост – бронирование ОС – накатить готовые политики с рекомендованными настройками безопасности от Microsoft Security Compliance Manager или доточить их под рекомендации – например, отключить SMB v1 как класс и прочие ненужные устаревшие сервисы – плевое дело, управление обновлениями (совсем не сложно, особенно, если Windows не пиратская), с IDS сложнее, но даже тут – всего лишь подписка на Defender Advanced Thread Protection, который, как показала практика, ловит атаки подобного типа на корню.
ЛПП – обучение не открывать файлы, предупреждение об возможных атаках и наказание – вплоть до увольнения и судебных исков против запустивших вирус (ах, да – страна такая, законы не работают – тогда просто переломайте запустившему вирус ноги).
Так что в данном случае – сам факт заражения существенно снижается…
Сценарий второй – вирус «прилетел» через обновление той или иной LoB-системы и здесь пока почти без шансов – скорее всего компьютер будет заражен, поскольку код выполняется от прав системы.
Но не будем расстраиваться. Мы потеряли один компьютер и далее все зависит исключительно от устойчивости ИТ-инфраструктуры в целом.
Дальнейший сценарий распространения вируса Petya проходит по нескольким направлениям:
Механизм, использующий уязвимость SMBv1 (EternalBlue/EternalRomance) на находящихся в одной подсети с зараженным ПК компьютерах,
Или механизм pass-the-hash/pass-the-ticket, используя имеющиеся на зараженном ПК сеансы пользователей.
Первый вариант распространения вируса на соседние ПК блокируется очень просто с Defense-in-Depth:
LAN – сегментирование и изоляция (VLAN) – совсем просто, особенно учитывая кол-во накупленных в компаниях Cisco и прочего оборудования, надо только сесть и чуть подумать, какой же трафик куда должен ходить между сегментам пользовательских ПК (многочисленных и разнесенных тоже) и серверами приложений (тоже сегментированных между собой по типам приложений и требуемого сетевого доступа). Мы не говорим даже об NDIS – даже без обнаружения вторжения (хотя если Cisco – так чего бы не активировать?) – сегменты сетей стали бы непреодолимым барьером для проникновения вируса вне группы ПК.
Хост – с его firewall, который, как ни странно, сейчас включается в Windows по умолчанию и только дурацкий ответ на вопрос – «хотите ли вы расшарить свои файлы в сети» – «да, хочу!» – портит всю картину. Ну вот зачем, зачем пользовательскому ПК вообще что-то публиковать в сети? Зачем все админы так любят отключать firewall? Легче работать? А не легче ли написать правила в групповых политиках… И все, даже в рамках одного сегмента сети – такие ПК c firewall будут защищены от посягательств зараженного ПК. А что насчет контроллеров домена и прочих файловых помоек – читай выше, обязательных обновлений и «бронирования» и тут никто не отменял.
ЛПП – и да, не забываем о персональной ответственности админов и сетевиков за каждый следующий поломаный по сети комп.
Второй вариант распространения вируса чуть сложнее – Petya использует для атаки на другие ПК в сети наличие открытых пользовательских сеансов/кэшей паролей на зараженном ПК, а учитывая парадигму того, что многие админы на ПК используют один и тот же пароль локального администратора или учетную запись администратора домена для работы на любом ПК компании – здесь для Petya широкое поле деятельности с использованием механизмов атак pth/ptt. Имея на руках администраторские пароли и открытые «всем ветрам» порты соседних ПК – Petya успешно копирует себя через административные шары (Admin$) и запускает удаленно свой код на атакуемой машине.
НО, если обратиться к Defense-in-Depth, то можно обнаружить, что:
Хост – рекомендовано использование технологий VBS и Device Guard для защиты от кражи идентити подобными способами. Но – VBS есть только в Windows 10 – Ok, но никто не мешает познакомиться с рекомендациями по защите хостов от Pass-the-hash/pass-the-ticket атак для Windows 7 и т.д. – ничего сложного, кроме опять же – использования рекомендованных шаблонов безопасности (их же можно использовать и для Windows 10 без VBS/DG) – http://aka.ms/pth – начиная с отключения кеширования идентити при входе и т.п.
Хост – простейшая гигиена аутентификации, связанная с использованием уникальных администраторских паролей на каждой рабочей станции/сервере – утилита Local Administrator Password Solution (LAPS) – http://aka.ms/laps – избавит от головной боли «по запоминанию» каждого пароля, а далее – более сложные процедуры гигиены для администраторов, которые говорят, что для выполнения определенных действий на ПК должны быть использованы определенные учетные записи, не обладающие полнотой прав на уровне всей сети – https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material (а что, никто не в курсе, что с доменным админом ходить по рабочим станциям категорически запрещено?).
Плюс – уже упомянутые выше механизмы обнаружения вторжения – тот же Defender ATP или Microsoft ATA («заточенный» как раз на обнаружение атак pth/ptt) и, безусловно – firewall и сегментирование сетей для того, чтобы завладевший теми или иными учетными записями вирус не смог подключиться к соседям.
ЛПП – а здесь уже может “прилететь” и админу компании в целом, если окажется, что его учетная запись “гуляет” почему-то по рабочим местам пользователей или используется на ПК совместно с такими гуляющими админами.
ВСЕ! Было «охренеть как сложно», мы потратили от силы 3 рабочих дня (24 часов и 24х75=1800евро денег высококвалифицированного специалиста) из предоставленных 43 дней с предыдущей атаки для того, чтобы защититься от разрушительного действия вируса типа Petya.
UPD 1: По просьбам комментаторов и просто друзей в Facebook и прочих социальных сетях – записал практическое видео с примером реальной лабы по заражению домена Petya.C с правильно настроенными политиками безопасности согласно требованиям Defense-in-Depth для защиты от современных типов угроз (типа того же Pass-the-Hash/Pass-tht-Ticket, которые использовал Petya.C) – при явном заражении одного ПК – влияние вируса на остальную лабу – нулевое:
Да, тут некоторые коллеги в комментах дискутировали насчет того, что «нельзя так просто взять и поделить сеть на подсети пользователей и банкоматов – есть моменты администрирования и удобства работы» – но, в любом случае, у CIO было еще минимуму 3-5 дней на подумать, а потом решить, что удобство работы перед угрозой полномасштабной вирусной атаки – отходит на второй план. В общем – даже не думали и не сделали НИЧЕГО.
Наши потери от Petya после принятых общих мер – мы потеряли, скорее всего, все машины, которые заразились путем приезда «обновления от MEDoc» (хотя, при использовании IDS типа Defender ATP – и эти потери могут быть сведены к минимуму), мы потеряли 10% от тех машин, которые получили «письма счастья», а компания – потеряла работавших на них сотрудников. ВСЕ! Никакой эпидемии, никаких отключившихся касс и банкоматов (!!!), никаких тысяч часов на восстановление ИТ-инфраструктуры. Осталось восстановить требуемые данные из бекапов (или вообще ничего не восстанавливать, кроме ОС на ПК – если ИТ-инфраструктура сделана правильно и все хранится и бекапится централизованно, к тому же – в облако).
Таким же образом, через обновления, Petya успешно бы пролез и на виртуалки в Azure, дальше бы пошел гулять по виртуальным сетям Azure (которые вы бы не поделили на сегменты, не изолировали, не использовали firewall на каждой), а потом и через Site-to-Site VPN залез бы и на наземные ПК пользователей… Или наоборот – с тем же результатом в такой незащищенной от угрозы изнутри “обланой” инфраструктуре.
А то было бы и хуже – учитывая умение Petya считывать учетные записи админов и зная безалаберность этих админов – Petya.Cloud (с модулем работы в облаке – дописать в код пару строчек) давно бы уже имел административные права на ваши подписки в облаках и делал бы там все, что заблагорассудится, кидая вас еще и на деньги – например – поднимал бы виртуалки для майнинга или ботсетей в вашей облачной подписке, за которые вы бы потом платили по 100К-300К уе/мес.
И даже использование облачного Microsoft Office 365, который вроде как SaaS и его инфраструктура защищается Microsoft – при такой дырявой инфраструктуре на местах – не спасет – с тем же успехом вирус добирается до админского аккаунта O365, используя воровство учетных записей – и дальше подписка O365 уже «не ваша».
Вам об этом не сказали Microsoft, Google, Amazon – все, кто продает «облака»? Так это, им же продать надо, а не решать ваши проблемы – а все проблемы облаков – находятся «на местах», а туда особо уже и не продашь – значит, и инвестировать в наземные части заказчиков не стоит ни копейки – даже тренингами и семинарами…
И всем – приготовиться – это была только следующая волна, ждем следующей, как только ребята найдут следующий механизм “заброски” и инфильтрации вируса в корпоративные сети. И этот вирус также не будет обнаруживаться антивирусами по сигнатурам и будет эксплуатировать свежие уязвимости сетей и незакрытые механизмы типа Pass-the-hash/Pass-the-ticket. И вот просто “перенести все в облака” вам не поможет, а подписка на облачные Microsoft ATA/Defender ATP в дополнение к описаным выше мерам – вполне.
И небольшой ликбез для тех, кому интересно (некоторые доклады – почти годичной давности):
Феерический факап «ИТ-нации», которая в реальности оказалась совсем не «ИТ нацией», а просто сборищем ремесленников-разработчиков «на галерах», способных писать код на заказ, но имеющих весьма отдаленное представление об ИТ в целом и безопасности в частности… Даже словацкое телевидение пнуло Украину, показав с утра в новостях сюжет с ремаркой типа “украинские специалисты не могут справиться с вирусом”…
История, как говорится, повторяется дважды – один раз в виде трагедии, второй раз – в виде фарса… В Украине произошел именно фарс с этим вирусом “Petya.A” – по другому никак нельзя назвать обрушение ИТ Украины более чем через месяц после основной волны аналогичных вирусов по всему миру и более чем через 4 месяца после того, как возможная уязвимость была пропатчена компанией Microsoft. А рекомендации по защите от подобных атак от Microsoft существуют уже более 10 лет в виде стратегии Defense-in-Depth.
И какие причины привели к данному фарсу в виде коллапса многих банков и учреждений из-за действий абсолютно банального вируса, возраст которого – более года и использующего в настоящий момент уязвимости 4хмесячной данности?
Дебилы, бл@
Только так можно на текущий момент охарактеризовать уровень CIO компаний, которые подверглись успешным атакам. Причем можно даже не детализировать – и так все ясно – достаточно сказать о том, что эти люди не сделали никаких выводов и телодвижений из крупных атак на мировые системы более месяца назад. И уже не важно, что стало окончательной причиной внедрения вируса – старые системы, отсутствие обновлений, действие пользователей, отсутствие той самой стратегии Defense-in-Depth – результат на лицо – никаких мер за целый месяц принято не было, вообще! Причем эти меры – ничего такого из ряда вон выходящего, что выходит за рамки включения тех или иных функций в ИТ-инфраструктуре компании (уже имеющихся «из коробки») и описанные в том же Defense-in-Depth.
Кстати, Defense-in-Depth достаточно часто рассматривался мной на различных докладах и выступлениях по безопасности и последний раз – 20 мая 2017 на «Стальном Бубне» – запись доклада здесь – https://youtu.be/4e2qwseGGNA?t=2m30s . Кстати, рекомендую обратить внимание на разницу в том, о чем сам доклад и почему он начинается именно с Defense-in-Depth.
Для Petya.A хватило бы соблюдения минимальных рекомендаций, в том числе таких, как firewall на всех ПК, закрывающий ненужные порты рабочих станций (они не серверы, и нечего «светить» портами, особенно непропатченными, даже в локальную сеть) и применение шаблонов и рекомендаций по безопасности, среди которых – и отключение уязвимых версий протоколов SMB. Ну заразились бы отдельные ПК, на которых пользователи открыли бы вредоносный файл – но это бы не приняло масштабы эпидемии, когда выносились целые сети таких вот «открытых всем ветрам» ПК. А еще большей загадкой для меня является то, каким образом связаны сети общего пользования в некоторых банках и сети банкоматов? Там что, пакетики в сети гуляют, как заблагорассудится и каждый внутренний пользователь теоретически, может добраться до каждого банкомата?
А рассказать сотрудникам о том, что открывать все файлы подряд и подтверждать запрос подсистемы безопасности – опасно – вообще запредельная задача для ИТ подразделений?! Не говоря уже о фильтрации ненужных почтовых сообщений и опасных файлов в них…
Но нет, украинским CIO – это не по силам, они там для другого сидят – пилить корпоративный/государственный бюджет на ИТ и делиться с таким же наемным руководителем этой компании. И, как мне кажется, ничего CIO этих компаний не будет (как говорится кум-сват-брат), зато если посмотреть на список атакованных компаний и сравнить его с вручением Best CIO Ukraine – и Ощадбанком в списке победителей – то хочется попросить организаторов публично отозвать эту номинацию, чтобы хоть кто-то из CIO прочувствовал, что все не просто так и ты не можешь быть “Best CIO”, если у тебя валится система. И, надеюсь, в следующем цикле отбора “лучших” – тема безопасности будет во главе угла с соответствующим аудитом – на наличие того самого Defense-in-Depth.
В реальности ситуация с Defense-in-Depth в крупном украинском предприятии выглядит примерно следующим образом (реальные данные).
Таблица требований Defense-in-Depth.
Уровень
Технологии
Данных
ACL/шифрование/классификация данных с RMS
Приложений
SDL, антивирусы, «бронирование» приложений и сервисов, App/Device Guard
Хостов
«Бронирование» ОС, аутентификация, управление обновлениями, FW, защита от вторжения (IDS), VBS, Device Guard
LAN
Сегментирование и изоляция (VLAN), шифрование (IPSec), защита от вторжения (NIDS)
Периметр
FW, контроль доступа, App FW, NAP
Физическая безопасность
Охрана, ограничение доступа, аппаратный контроль и аудит доступа, отслеживание устройств, камеры наблюдения
Люди, политики, процедуры
Документирование, тренинги, предупреждения и уведомления, наказания…
Согласно проведенному опросу, службы безопасности, рекомендованные в Defense-in-Depth, реализованы в ограниченном объеме для каждого из уровней.
Защита данных – отсутствует
Защита приложений – отсутствует
Защита хостов – реализованы 2 требования к защите (аутентификация, управление обновлениями) данного уровня из 8ми
Защита локальной сети – 1 требование (VLAN) из 3х
Защита периметра – 2 (FW, контроль доступа) требования из 4х
Физическая защита – 3 (Охрана, ограниченный доступ, контроль) из 5
Кадры решают все – это сказал фараон… Может, при «таких» CIO и хороших, инициативных и ответственных админах-исполнителях на более низких позициях, которые бы проявили инициативу и сами, еще в марте 2017 года, аккуратненько пропатчили бы системы и приняли остальные рекомендуемые меры – вируса не смог бы разгуляться в таких масштабах.
НО – таких админов в украинском ИТ просто не существует. Потому что «ИТ-псевдонация» вообразила, что только аутсорсеры-девелоперы могут зарабатывать нормальные деньги, толковый системный администратор же не стоит более 500 баксов, а в лучшем случае – и 150 баксов ему хватит. Что вызвало естественный отток из этого направления ИТ наиболее толковых специалистов – тех, кто хотел и умел переучиваться – они ломанулись в «devops» и прочие, смежные с лавками галер, позиции, присасываясь к денежным потокам аутсорса. Самые умные – плюнули на весь этот бедлам и просто уехали «на постоянку» в нормальные страны с соответствующим уровнем развития ИТ и пониманием места и стоимости ИТ-специалистов в современном мире.
На смену им в украинские компании пришли те, кто вдруг «внезапно» решил «уйти в ИТ» из «менеджеров» и прочих «по работе с клиентами» с редкими вкраплениями «молодой поросли» системных администраторов после ВУЗов (которые, ВУЗы, как бы не надували свои щеки – никаких системных администраторов даже в базовом представлении не готовят).
Кстати, о ВУЗах – имел тут возможность пообщаться с некоторым количеством «перспективных молодых сисадминов», которые заканчивают ВУЗ и многому научились – в направлении ИТ администрирования и т.п. на ведущих ИТ кафедрах украинских ВУЗов не рассказывают даже о теоретических основах ИТ-инфраструктуры, таких, как IT Infrastructure Optimization Model/IT Infrastructure Maturity Model, что, на мой взгляд, должно быть фундаментом знаний для любого, кто выходит из ВУЗа со специальностью типа «ИТ-специалист». О чем я? Да вот об этом – Модель оптимизации ИТ – http://bit.ly/CoreIOmod – хотя бы 8 часов лекций в план обучения можно добавить?
150 баксов – компании довольны, платить больше не надо, CIO репортят о внедрении новых систем для бизнеса, ИТ платформа продолжает быть лоскутной и дырявой – и всем хорошо. Было…
Когда тыкаешь носом в проблему – «Ок, проблемы есть, мы работаем, может привлечем кого-то со стороны, вот вас, например» – «75евро/час» – «сколько? Да вы что, мы таких денег в ИТ не платим!». Сейчас злорадно потираю руки, вспоминая разговор начала февраля…
Вывод только один – никакой украинской «ИТ-нации» не существует и не будет существовать еще долго. Сейчас есть какая-то «псевдонация» химерного вида с аутсорсерами, которые клепают код на заказ и считающими, что они держат Бога за бороду. Данная вирусная атака показала же полную несостоятельность Украины, как ИТ-страны.
Российский след…
«Патриоты» сразу устроили истерику «это необъявленная ИТ-война», нас атакуют! Расслабьтесь – никакие спецслужбы не причастны напрямую к данной атаке, ибо она является фарсом по своему смыслу и содержанию. Если к этой атаке причастны ФСБ и прочие подразделения – то кроме как полным тотальным ФАКАПОМ и провалом такую атаку от ФСБ назвать нельзя. Почему? Да все очень просто – имея так отлично работающий механизм инфильтрации в чужую сеть – профакапить возможности многолетнего контроля и планомерного изъятия информации из зараженных сетей, которые предоставляла данная атака – могли только дилетанты-школьники, решившие, что номер их Bitcoin достаточно защитит их анонимность и они получат миллионы баксов и свалят на Карибы…
О чем я?! Если бы я, как сотрудник соответствующего подразделения ФСБ, планировал атаку и имел бы на руках подобный механизм вторжения – никогда ни за что я бы не шифровал файлы, я бы использовал дальше pass-the-hash, pass-the-ticket атаки для получения всех требуемых мне аккаунтов и спокойно и незаметно контролировал бы сети крупнейших компаний Украины без какой бы то ни было огласки. Годами! Потому что CIO и ИТ-персонал украинских компании в 90% случаев не то, что не готово к таким атакам, а даже не в курсе, что это такое и как защищаться.
И в таком случае ФСБ получало бы стратегическое преимущество вместо тактической «хулиганской» победы – представьте себе права Enterprise Admin’а в Ощадбанке? А в -энерго? А на Чернобыльской АЭС или в Аэропорту «Борисполь»? Вы можете читать базы, смотреть транзакции и, не дай бог (хотя я допускаю и такую возможность – объединение технологических и офисных сетей при украинском общем ИТ-пофигизме) управление системами навигации или контроля за «Укрытием»… Представили?
Так что либо ФСБ – идиоты, либо «Путин всех переиграл», либо – украинский псевдопатриотический ИТ-бомонд опять прикрывает свою полную некомпетентность «войной»…
Кстати, коллеги из СБУ – я бы все же проверил насчет pth/ptt зараженные Петей системы после ввода их снова в эксплуатацию во избежание описанного выше сценария. Нужны консультации – вы знаете, как меня найти… Нет, в Украину не поеду.
А хакерам-недоучкам остается сказать только – ВЫ ИДИОТЫ, ВЫ ТОЛЬКО ЧТО ПРОВТЫКАЛИ СВОЙ ШАНС ИМЕТЬ НЕОГРАНИЧЕННЫЙ НЕКОНТРОЛИРУЕМЫЙ ДОСТУП КО ВСЕМ РЕСУРСАМ ЦЕЛОЙ СТРАНЫ ГОДАМИ!!!
Феерический факап Microsoft Ukraine
Самый же большой факапер в данной ситуации – это Microsoft Ukraine. И не потому, что вирус поражает Windows, а потому, что данное региональное подразделение Microsoft в Украине не предприняло никаких действий по предупреждению угрозы и защите своих заказчиков (а пострадали крупные заказчики) от возможных будущих атак. Вот просто НИКАКИХ! Ни в тот момент, когда в марте 2017 вышел патч, который был настолько критическим, что о нем трубили все, кому ни лень, ни в тот момент, когда через месяц, в апреле 2017, вышел эксплоит на дырку, ни в мае 2017, когда пошла первая волна атак – ни в один из этих моментов Microsoft Ukraine не разродился ни коммуникацией к заказчикам, ни к обширной базе своих подписчиков на рассылки, ни какими бы то ни было семинарами или даже вебкастами – просто тишина… Зачем?! Действительно, Интернет, народ читает про вирус, вдруг сам додумается закрыть дырки. Не додумался.
Ах, нет специалистов соответствующего профиля в Microsoft Ukraine?! Серьезно?! Безопасность, которая является критическим аспектом в ИТ – никак не представлена в Microsoft Ukraine соответствующей позицией? И при этом компания позиционирует локальный офис в том числе и как инструмент для поддержки пользователей?! – Тогда грош цена такому инструменту, который за полгода никак не смог прореагировать на громадную потенциальную угрозу и палец о палец не ударил, не потратил ни тысячи маркетинговых денег, чтобы хоть как-то донести информацию и об угрозах, и о мерах противодействия им, до своих заказчиков (вот специально зашел в подписки и посмотрел на коммуникации от Microsoft Ukraine – НИ-ЧЕ-ГО).
Впрочем – ситуация тут во многом аналогична ситуации на украинском рынке ИТ в целом, которая описана выше… С ослепленностью носорога Microsoft Ukraine уже 5 лет прет вперед девизом «Девелоперс! Клауд!» и полным отрицанием необходимости работать с ИТ-специалистами в целом и с безопасностью – в частности. Чего стоит проведенное с помпой многодневное мероприятие для девелоперов по блокчейну, проведенное в Киеве – прямо как пир во время чумы. Можно было бы хотя бы 20% этих денег потратить на то, чтобы рассказать про WannaCry и прочую хрень с EternalBlue и методы противодействия, вплоть до Defense-in-Depth – с соответствующими трансляциями и распространением материалов, можно было вебкасты организовать, в течение 4х месяцев с соответствующей рекламной поддержкой. Ага, фиг там!
Особенно порадовало вчера, в разгар вирусной атаки, сообщение в ФБ от менеджера Microsoft Ukraine по коммуникациям – «Ми працюємо! Триматиму в курсі справ.» – что, серьезно?! Афигеть, как оперативно сработали! Защитили! Даже перевода статьи месячной давности https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/ не опубликовали… Кстати, письма в массовых рассылках про угрозу и с рекомендациями – так и не появилось. На текущий момент 28.06.2017 12:00 молчит также и группа ФБ – Спільнота ІТ-фахівців Microsoft в Україні – https://www.facebook.com/ITproCommunity/– постит только смешные гифки, у них же праздник и выходной – проблемы пользователей в праздник никого не волнуют.
«Девелоперс! Ажур! Все в облака!» – при этом сами сотрудники компании плохо себе представляют те угрозы, которые несет насквозь дырявая локальная ИТ-инфраструктура облачной инфраструктуре заказчика и какие затраты могут возникнуть в случае взлома (об этом тоже здесь – https://youtu.be/4e2qwseGGNA) и везде, где только возможно, об этом умалчивая. Мало того, они слабо представляют себе и тот момент, что имидж продуктов Microsoft после подобных атак катастрофически испорчен, и даже не важно, что локальный ИТ профакапил не меньше – выбор заказчиками следующих продуктов, в том числе и облачных – будет не в пользу Microsoft и продавать Azure и облачные сервисы Microsoft после такого факапа будет еще сложнее, как бы не рассказывали «продажники» о высокой защищенности облаков (что, на сама деле – тоже неправда).
Так что данная атака – самый крупный и тотальный факап Microsoft Ukraine за все годы его существования и громадная дыра в стратегии компании в целом. И можно сказать, что на Microsoft Ukraine и его бездеятельности – лежит большая часть ответственности за произошедшее. Хотя и не думаю, что они сделают из этого какие-то выводы, кроме того, что продолжат свои преследования «инакомыслящих»…
И на этой ноте – хочу пожелать становления украинскому ИТ, после такой смачной публичной пощечины, думаю, некоторые таки задумаются про то, сколько реально стоит ИТ и почему не «рабы на галерах», а админы являются ИТ-специалистами и определяющей составляющей «ИТ-нации» и сколько им надо платить, чтобы подобное не повторилось. И учиться, учиться и еще раз учиться… Хотя я слабо представляю, как это будет делать “пересичный” украинский ИТ-администратор, который загружен по уши на работе текучкой (он же ИТ-дженералист по сути), денег на обучение у него нет (на 150 долларов – тут бы выжить), а Microsoft и прочие компании – “слились” из данного сегмента развития рынка… А отдельным ИТшникам – учитесь, развивайтесь, валите из этой страны, где ваши знания никто не оценит, туда, где есть реальный спрос и реальные задачи потому что, как мне кажется, весь этот шмон закончится просто очередным распилом бюджета…
Ах, да! Что делать?! Если срочно – просто снесите все (надеюсь, бекапы у вас есть) и установите начисто новую лицензионную Windows 10 со всеми обновлениями и влюченными сервисами защиты. Если данные важны и “потерпит” – дождитесь расшифровщика – скорее всего, учитывая объем атак – он появится. Для тех, кто еще не подхватил, но в зоне риска – обязательно следуйте рекомендациям Microsoft – https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/ , научите своих пользователей ничего не запускать из Инета и удачи!
UPD 01: И, в дополнение, уже по комментам в Facebook на статью, хочу добавить замечательные слова, которые сказал Коля Бобух (сам я как-то поторопился с написанием статьи, так сказать, “на одном дыхании” писалась):
Nick Bobukh Также, я бы продлил логическую цепочку твоих рассуждений насчёт “АйТи нации” и “войти вайти” имени некоторых распиаренных в ФБ личностей. Страна нихера не производит _конечного продукта_ (т.е. от слова совсем). Кто не верит, пусть пересчитает в денежном эквиваленте украинские вещи на себе, софт на компе, гаджеты, авто в гараже, даже квартиры если подумать, строятся на 50% из импортных материалов и на 100% импортной техникой по импортным же технологиям. ИТ не может быть вещью в себе, как утверждают апологеты “ИТ нации”, это часть экономики, причём не самая большая (Испания например нихера не “ИТ нация”, но и уровень и оборот в бабле ИТ области там на порядок больше чем у нас, потому что и экономика больше). А если у нас государство не может обеспечить даже неприкосновенность права собственности, то о каком росте может идти речь 🙂 Это значит, что добавочной стоимости, которая может идти в том числе на ИТ – нет. Отсюда и квадратные глаза при более чем гуманных рейтах.
Кроме того, вы узнаете о тех тенденциях, которые сейчас имеют место на рынке стартапов и почему лаборатория IoT Lab начинает потихоньку переходить от “обычных железячных” IoT решений все больше к программно-аппаратным или даже программным решениям.
А продолжение про работу Microsoft IoTLab Ukraine – следует. Один из стартапов в лице девушки Аллы с удовольствием согласился рассказать, как им работается в IoT Lab.
Потому – за всех отдувалась Алла, рассказывая как о проекте Finder, так и о других их проектах. Да-да, не смотря на свою молодость и красоту – Алла и Катерина уже достаточно преуспели в ИТ-бизнесе – можете заглянуть на домашнюю страницу их проектов – itcreative.com.ua
И, конечно же, про сам проект Finder, хотя Алла и сама достаточно подробно рассказала уже о нем в видео. Идея – проста, как и у всех других стартапов 😉 В данном случае – трекер велосипеда, но не сколько “фитнесовый”, сколько аварийный – на случай кражи или потери. Насколько для велосипедистов кража любимого протюненого велосипеда – это боль – можете послушать в интервью пана Вовки из Братиславы.
Что будет делать гаджет от Finder? Будучи встроенным в руль “обычного” или “необычного” велосипеда – он будет исправно “стучать” о местоположении велосипеда, взятом с GPS, в соответствующий сервис через модуль 3G. Обещают минимум 3 дня без подзарядки и дополнительную опцию, которая позволит заряжать модуль от динамомашинки (генератора) – но это пока еще в стадии обсуждения и планирования
Ничего особенного? Да, но уже полезно… НО, кроме всего прочего поисковый гаджет от Finder будет еще иметь и модуль Bluetooth, который позволит велосипедистам организовывать “социальные игры” типа “охоты на лис” или “догони вора”. О чем это? А дело в том, что благодаря Bluetooth Finder, находящийся в режиме “кражи” (владелец может удаленно установить такой через вебпортал или приложение) начинает броадкастить на все находящиеся в зоне доступности Bluetooth устройства… И, конечно же, на соседние Finder.
А мне остается только пожелать девушкам удачи и успеха в их интересной задаче с Finder и в ИТ-бизнесе вообще Надеюсь, свой первый миллион они заработают уже в этом году на Finder.
В этой части – переходим от подготовки рабочего места к изучению конкретных технологий и служб, которые необходимо внедрять в ИТ-инфраструктуру мало-мальской организации (от 15-20 ПК и выше).
Такой службой в инфраструктуре, которая обеспечивается сервисами Microsoft, является Microsoft Active Directory (а если быть точным – то конкретная служба Microsoft Active Directory Domain Services).
Поэтому – изучение базовых основ Active Directory является первой же обязательной и неотъемлимой частью обучения будущего Системного Администратора. И даже если вы решили стать Системным Администратором на другой стороне – различных систем Linux и т.п. – концепцию каталога для единой аутентификации вам все равно придется учить – она таки краеугольная, не зависимо от используемых технологий – и, таки и саму Active Directory – очень часто в инфраструктурах мне приходилось встречать те самые Linuxвые серверы, приложения которых использовали для своей работы аутентификацию Active Directory – как лучшего решения в своем классе 😉
Базовые концепции управления учетными записями, аутентификацией и правами доступа
Установка роли AD DS на первый контроллер домена
Базовые концепции Active Directory Domain Services
Управление и настройка Active Directory Domain Services
Добавление серверов и рабочих станций в домен AD
Управление учетными записями и группами безопасности
Контейнеры/Organizational Unit в AD DS
Кратко о групповых политиках
Да, я знаю, получилось длинно, но если вы действительно стремитесь получить те знания, которые необходимы Системному Администратору – думаю, просмотрите это видео внимательно и повторите у своей лаборатории 😉
В этой части – продолжаем тему изучения конкретных технологий и служб, которые необходимо внедрять в ИТ-инфраструктуру мало-мальской организации (от 15-20 ПК и выше). После развертывания домена Active Directory Domain Services и настройки единой аутентификации пользователей (в предыдущем видео) – разбираемся с тем, что называется AD Group Policy и как с помощью политик настраивать рабочие места в домене и с тем, что такое делегирование полномочий на работу с ADDS – создание пользователей, групп, добавление пользователей в группы и т.п.
Базовые концепции физической и логической структуры AD DS
Добавление компьютеров в домен
Немного об управлении облегченным вариантом установки Windows Server Core Installation
Добавление дополнительных контроллеров домена в AD DS
Создание сайтов AD DS в домене/лесу
Понятие репликаций AD DS и управление ими
Добавление нового домена в лес AD DS
Резервное копирование контроллеров домена AD DS
Продолжение данных учебных материалов – следует. Смотрите подробнее про возможности установки и управления варинтами установки Windows Server 2016 – Core Installation и Nano Server, а также – далее – управление сетевыми службами в Windows Server 2016.
Предыдущие части этого сериала – первые шаги по созданию тестового рабочего места:
Если вы уже практикующий системный администратор – то можете смело промотать это видео – оно больше направлено на тех молодых и не очень людей, кто от продвинутого юзера или эникейщика решил перейти на следующему уровню – стать таки системным администратором.
Как ни странно, но все же Windows 10 является “правильным” рабочим местом системного администратора, с которого он может удаленно управлять и серверами, и использовать встроенную в Windows 10 службу вирутализации Hyper-V для развертывания тестовых виртуальных машин и экспериментов на них. А если мы говорим о домашнем компьютере, который используется и для игр, и для обучения – то тут, однозначно, и альтернативы нет
Еще раз обращу внимание на минимальные требования к такому рабочему месту, чтобы на нем имелась возможность нормально работать с виртуальными машинами под Windows 10 Hyper-V, следующие:
Intel CPU x64 + аппаратная поддержка виртуализации (Intel VT, DEP, XD, SLAT/EPT и т.п.)
ОЗУ: не менее 8ГБ
Диск: самая главная часть – очень и очень нужен достаточно объемный SSD (от 256ГБ и более, желательно – отдельный) или аппаратный RAID с быстрыми HDD
Настройка службы Hyper-V, понятие виртуального сетевого коммутатора
Как скачать бесплатно Windows Server 2016 и Windows 10 Enterprise
Как установить Windows Server 2016/Win10 в виртуальные машины
Как создать клонируемый образ (шаблон) установленной и настроенной виртуальной машины с Windows Server/Windows 10 для быстрого развертывания нескольких ВМ
Как развертывать виртуальные машины из шаблонов
а также – подготовить флешку для установки отдельного сервера Windows Server 2016 на отдельное железо для следующей части…
В этом видео – практические рекомендации и выработанные годами практики по организации небольшой тестовой инфраструктуры с использование “основного” рабочего места и “условного” сервера виртуализации для самообучения и различных тестовых лаб.
Еще раз обращу внимание на минимальные требования к такому рабочему месту, чтобы на нем имелась возможность нормально работать с виртуальными машинами под Windows Server 2016 Hyper-V, следующие:
Intel CPU x64 + аппаратная поддержка виртуализации (Intel VT, DEP, XD, SLAT/EPT и т.п.)
ОЗУ: не менее 8ГБ
Диск: самая главная часть – очень и очень нужен достаточно объемный SSD (от 256ГБ и более, желательно – отдельный) или аппаратный RAID с быстрыми HDD
Если вы уже практикующий системный администратор – то можете смело промотать это видео – оно больше направлено на тех молодых и не очень людей, кто от продвинутого юзера или эникейщика решил перейти на следующему уровню – стать таки системным администратором.
В отличие от предыдущих видео – часть 1 и часть 2 – где речь шла о рабочем месте с использованием имеющихся достаточно мощных физических компьютеров – в этом видео мы используем облачные ресурсы Microsoft Azure – https://azure.microsoft.com/ – где мы берем в аренду требуемые ресурсы. Первый, тестовый, месяц вы можете использовать бесплатно 200 долларов и создавать/запускать на них виртуальные машины, чтобы потестировать или поучиться какой либо возможности различных ОС.
Обзор доступных решений в Магазине Azure и цен на Azure IaaS
Создание виртуальных машин в Azure IaaS
Удаленное подключение к облачной виртуальной машине и работа с ней
Мониторинг состояния виртуальных машин и состояния счета подписки
И этой серией мы заканчиваем вступительную часть практического руководства о том, как стать Системным Администратором – о подготовке тестовой лаборатории 😉
В следующих частях – смотрите более подробно про различные роли и функции Windows Server 2016, которые обязательно должны быть знакомы Системному Администратору и, конечно же, рекомендации, как их изучать более подробно
Не прошло и 2х лет, как я закончил первую – теоретическую – часть цикла видео про ИТ-карьеру из пяти частей. Специально для тех, кто планирует посвятить свою жизнь такой неблагодарной специальности, как ИТ специалист (или IT Professional – ITPro – как говорят у «буржуев», и не стоит путать с разработчиками).
В первой серии про развитие ИТ-карьеры – смотрите о 3х основных составляющих успешной карьеры как для ИТ-специалиста (системного администратора), так и, во многом, разработчика:
Потдвержденный практический опыт работы с продуктами и задачами – это еще одна очень важная составляющая успешной ИТ-карьеры. Можно “обвешаться” сертификатами и не уметь применять полученные знания на практике, решая реальные технические и бизнес-задачи с использованием ИТ, выполняя реальные проекты для заказчиков разных размеров. Про то, как приобретать практический опыт, особенно – без наличия требуемого дорогого и мощного оборудования – мы поговорим в одном из следующих видео, посвященных развитию ИТ-карьеры.
Умение говорить с людьми, и, особенно, с бизнесом – поскольку ИТ, особенно то, где работают системные администраторы – является не самостоятельной организацией, а сервисным подразделением предприятия. И задача любого ИТ-специалиста – обеспечить эффективное решение бизнес-задач предприятия с применением тех или иных технологий. И умение трансформировать технологические фичи продуктов в работу бизнеса – одно из основных требований успешной карьеры ИТ-специалиста, особенно того, кто хочет зарабатывать “ну очень много”, а такое возможно только на позициях руководителей ИТ-департаментов или как ИТ-консультанта, решающего, например, задачи развития ИТ-инфраструктуры крупного предприятия. Чтобы понимать всю прорву задач в этом направлении – я рекомендую посмотреть этот плейлист – Модель Оптимизации ИТ-инфраструктуры.
Собственно, я постарался выделить все те личностные качества, навыки и действия, которые являются наиболее критичными для достижения успеха в ИТ карьере для системного администратора (и не только), и с развития и совершенствования которых у «себя любимого» стоит начать развитие своей карьеры.
Почему IT Generalist является важной ступенькой в карьере? Потому что без практического опыта, «приложения рук» к практическим вещам, понимания потребностей и запросов пользователей и бизнеса – «нельзя вот так просто взять и стать системным администратором». Сначала надо 2-3 года минимум поработать на подхвате, изучая на практике все глюки и багофичи, с которыми потом придется встретиться уже будучи системным администратором, у которого зона ответственности куда шире – и не только в технологиях, но и в работоспособности самого бизнеса.
Какими навыками должен обладать IT Generalist, что является его основными задачами и зонами ответственности, какие основные инструменты работы у эникейщика – все это в данном видео.
Смотрите в видео – кто такой системный администратор, чем он занимается, какие задачи стоят перед системным администратором, что он должен уметь и знать, с какими проблемами сталкивается системный администратор в ходе своей работы.
И, главное, сколько зарабатывает системный администратор и что надо знать и уметь для того, чтобы, будучи системным администратором, зарабатывать по максимуму. И какие есть возможности развития карьеры у системного администратора.
Можно долго спорить о том, что должен или не должен делать системный администратор, в конце концов – должностные обязанности позиции с громким названием “системный администратор” определяет работодатель (а в странах с колониальной экономикой они могут быть и типа “раб-системный администратор обязан менять резину на Порше шефа”) – в данном случае в этом видео о работе системного администратора автор высказывает свое личное мнение, сформировавшееся за 22 года работа в индустрии ИТ, в основном – системным администратором или консультантом, и, большую часть этого времени – на крупные западные фирмы Да-да такая вот длинная история, и это только подтвержденные 22 года работы в ИТ, о которых официально “говорит” моя “трудовая книжка”, а вообще, моя “дружба” с компьютерами началась в далеком 1986 году с Atari – но это уже совсем другая история и про ее начало и Atari – здесь.
резюме должно быть правильной структуры (структурированный шаблон резюме есть в шаблонах Microsoft Word)
резюме – это ваша визитная карточка, она должна быть лаконичной, с четко выраженными мыслями, доступными контактами и не более 2-3х страниц текста
Указывайте только необходимую личную и контактную информацию – в адресе достаточно только города и страны, email и телефона. Скайп – по желанию. И посмотрите внимательно, чтобы ваш email выглядел прилично – без всяких “васьОк” и т.п.
Используйте буллеты для выделения всей важной информации – будь то ваш опыт работы в начале резюме, или должностные обязанности и достижения на разных позициях
в опыте постарайтесь конкретизировать и лаконично представить все свои знания и умения, выделив при этом те, которые больше всего подходят для новой позиции. Опыт работы – это компиляция и лаконизация всех ваших должностных обязанностей и достижений, указанных ниже. И не забудьте в начале указать общий опыт работы в ИТ-индустрии в ГОДАХ (а не с такого-то года!!!)
в знаниях технологий – не надо перечня аббревиатур-названий продуктов и технологий – требуются четкие обозначения сервисов (с полным названием продукта) и указанием опыта работы с продуктом – это внедрение, администрирование, поддержка и т.п. Про сервисы – очень рекомендую посмотреть видео о Модели Оптимизации ИТ-инфраструктуры
также избегайте перечисления устаревших версий, которые вы в реальности уже в глаза не видели (например, лично я сейчас вижу Windows Server 2003 только в процессе миграции, потому какие-то нюансы администрирования и его функций могу и не помнить) – при указании таких продуктов следует четко писать, что вы сейчас реально делаете на старых платформах
и еще – избегайте заявлений типа “‘эксперт по Windows”, “знаю DHCP, DNS”. Вы уверены, что вы “эксперт”? – экспертом по Windows я могу назвать только одного человека – Марка Руссиновича 😉 Вы хотя бы можете рассказать на базовом уровне про внутреннюю архитектуру Windows? А про процедуры автоматического развертывания? А про работу систем безопасности? Аналогично – упоминание DHCP – что DHCP? Вы знаете протокол? Или сервер DHCP? На какой платформе, в каких инфраструктурах? Можете спанировать DHCP для организации с 10000ПК в 20 локациях?
Второе бонусное видео – мой коллега из офиса Microsoft Украина Сергей Поплавский https://www.facebook.com/sergey.poplavskiy.35 воспользовался случаем (когда я хотел записать просто обзор Starter Pack for Windows 10 IoT Core on Raspberry Pi 2), чтобы рассказать о тех перспективах в заработке и карьере, которые открывает перед специалистами, которые хотят что-то делать своими руками, направление Internet of Things (IoT).
И о своей лаборатории Microsoft Ukraine IoTLab – www.iotlab.in.ua – которая поддерживает начинающие стартапы, предоставляя место, оборудование, тренинги (не только технические, но и бизнесовые) для тех, кто растит и лилеет свой проект в направлении IoT на технологиях Microsoft.
Так что если у вас есть идеи о том, какое интересное устройство можно реализовать, вам не нравится “работать на дядю” и “получать зарплату” и вы хотите реализовать себя, как успешного разработчика уникального решения – вам как раз в Microsoft Ukraine IoTLab.
Кстати, Сергей в видео подробно рассказывает, в каких направлениях www.IoTLab.in.ua сейчас отбирает проекты на следующую интерацию (это сентябрь 2016 года) и какие критерии отбора 😉
Так что у вас есть еще немного времени для того, чтобы сделать свой первый шаг в ИТ-карьере успешного разработчика программно-аппаратных решений и заработать свой первый миллион. Придумываем идею, покупаем Starter Pack for Windows 10 IoT Core on Raspberry Pi 2, различные датчики и элементы на китайских сайтах, паяльник и измерительные приборы, качаем весь нужный софт отсюда https://developer.microsoft.com/en-us/windows/iot , внимательно изучаем примеры и демо там же – и с паяльником и клавиатурой в руках – к мировой известности благодаря своему новому суперинтересному гаджету или системе контроля/упраления чем-то
А я может найду время между своими проектами, поездками и хобби – и все же мы решим с Сергеем длительный спор насчет того, “может ли Админ стать разработчиком” (про то, может ли разработчик быть админом – мы уже узнали – нет, не может, разработчик всегда пытается изобрести велосипед и пишет какие-то “костыли”, которые еще и криво работают – вместо того, чтобы почитать документацию на то, что сделано уже до него). Так что, глядишь, я еще и сам напишу что-то для управления своей ЖД с использованием Raspberry Pi и IoT.
🙂
Igor "Walker" Shastitko 