По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Микросервисы – это шаблон сервис-ориентированной архитектуры, в котором приложения создаются в виде наборов небольших и независимых сервисных единиц. Такой подход к проектированию сводится к разделению приложения на однофункциональные модули с четко прописанными интерфейсами. Небольшие команды, управляющие всем жизненным циклом сервиса могут независимо развертывать и обслуживать микросервисы.
Термин «микро» относится к размеру микросервиса – он должен быть удобным в управлении одной командой разработчиков (5-10 специалистов). В данной методологии большие приложения делятся на крошечные независимые блоки.
Что такое монолитная архитектура?
Если говорить простым языком, то монолитная архитектура – это как бы большой контейнер, в котором все компоненты приложения соединяются в единый пакет.
В качестве примера монолитной архитектуры давайте рассмотрим сайт для электронной торговли. Например, онлайн-магазин.
В любом таком приложении есть ряд типовых опций: поиск, рейтинг и отзывы, а также оплаты. Данные опции доступны клиентам через браузер или приложение. Когда разработчик сайта онлайн-магазина развертывает приложение, это считается одной монолитной (неделимой) единицей. Код различных опций (поиска, отзывов, рейтинга и оплаты) находится на одном и том же сервере. Чтобы масштабировать приложение, вам нужно запустить несколько экземпляров (серверов) этих приложений.
Что такое микросервисная архитектура?
Микросервисной архитектурой называется методика разработки архитектуры, позволяющая создавать приложения в виде набора небольших автономных сервисов для работы с конкретными предметными областями. Такой вариант структурированной архитектуры позволяет организовать приложения в множество слабосвязанных сервисов. Микросервисная архитектура содержит мелкомодульные сервисы и упрощенные протоколы.
Давайте рассмотрим пример приложения для онлайн-торговли с микросервисной архитектурой. В данном примере каждый микросервис отвечает за одну бизнес-возможность. У «Поиска», «Оплаты», «Рейтинга и Отзывов» есть свои экземпляры (сервер), которые взаимодействуют между собой.
В монолитной архитектуре все компоненты сливаются в одну модель, тогда как в микросервисной архитектуре они распределяются по отдельным модулям (микросервисам), которые взаимодействуют между собой (см. пример выше).
Коммуникация между микросервисами – это взаимодействие без сохранения состояния. Каждая пара запросов и ответов независима, поэтому микросервисы легко взаимодействуют друг с другом. Микросервисная архитектура использует федеративные данные. Каждый микросервис имеет свой отдельный массив данных.
Микросервисы и монолитная архитектура: сравнение
Микросервисы
Монолитная архитектура
Каждый блок данных создается для решения определенной задачи; его размер должен быть предельно малым
Единая база кода для всех бизнес-целей
Запуск сервиса происходит сравнительно быстро
На запуск сервиса требуется больше времени
Локализовать ошибки довольно просто. Даже если один сервис сломается, другой – продолжит свою работу
Локализовать ошибки сложно. Если какая-то определенная функция не перестает работать, то ломается вся система. Чтобы решить проблему, придется заново собирать, тестировать и развертывать приложение.
Все микросервисы должны быть слабо связанными, чтобы изменения в одном модуле никак не влияли на другой.
Монолитная архитектура тесно связана. Изменения в одному модуле кода влияет на другой
Компании могут выделять больше ресурсов на самые рентабельные сервисы
Сервисы не изолированы; выделение ресурсов на отдельные сервисы невозможно
Можно выделить больше аппаратных ресурсов на самые популярные сервисы. В примере выше посетители чаще обращаются к каталогу товаров и поиску, а не к разделу оплат. Таким образом, будет разумнее выделить дополнительные ресурсы на микросервисы каталога товаров и поиска
Масштабирование приложения – задача сложная и экономически не выгодная
Микросервисы всегда остаются постоянными и доступными
Большая нагрузка на инструменты для разработки, поскольку процесс необходимо запускать с нуля
Федеративный доступ к данным, благодаря чему под отдельные микросервисы можно подбирать наиболее подходящую модель данных
Данные централизованы
Небольшие целевые команды. Параллельная и ускоренная разработка
Большая команда; требуется серьезная работа по управлению командой
Изменения в модели данных одного микросервиса никак не сказывается на других микросервисах
Изменения в модели данных влияют на всю базу данных
Четко прописанный интерфейс позволяет микросервисам эффективно взаимодействовать между собой
Не предусмотрено
Микросервисы делают акцент на продуктах (модулях), а не проектах
Сосредоточены на проекте в целом
Отсутствие перекрестных зависимостей между базами кода. Для разных микросервисов можно использовать разные технологии
Одна функция или программа зависит от другой
Сложности в работе с микросервисами
Микросервисы полагаются друг на друга, поэтому необходимо выстроить коммуникацию между ними.
В микросервисах создается больше модулей, чем в монолитных системах. Эти модули пишутся на разных языках, и их необходимо поддерживать.
Микросервисы – это распределенная система, так что, по сути, мы имеем дело со сложной системой.
В разных сервисах используются свои механизмы; для неструктурированных данных требуется больший объем памяти.
Для предотвращения каскадных сбоев необходимо эффективное управление и слаженная командная работа.
Трудно воспроизвести ошибку, если она пропадает в одной версии и вновь появляется в другой.
Независимое развертывание и микросервисы – вещи слабо совместимые.
Микросервисная архитектура требует большего количества операций.
Сложно управлять приложением, когда в систему добавляются новые сервисы.
Для поддержки всевозможных распределенных сервисов требуется большая команда опытных специалистов.
Микросервисы считаются дорогостоящими решениями, поскольку для разных задач создаются и поддерживаются разные серверные пространства.
Сервис-ориентированная архитектура (СОА) или микросервисы
СОА-сервисы (SOA - Service-oriented architecture) поддерживаются через реестр, который считается перечнем файлов каталога. Приложения должны найти сервис в реестре и вызвать его.
Иначе говоря, СОА похож оркестр: каждый музыкант играет на своем инструменте, а всеми артистами управляет дирижер.
Микросервисы – это разновидность СОА-стиля. Приложения создаются в виде набора небольших сервисов, а не цельной программы.
Микросервисы похожи на труппу артистов: каждый танцор знает свою программу и не зависит от других. Даже если кто-то забудет какое-то движение, вся труппа не собьется с ритма.
Теперь давайте поговорим о различиях между СОА и микросервисах.
Параметр
СОА
Микросервисы
Тип проектирования
В СОА компоненты приложения открыты для внешнего мира; они доступны в виде сервисов
Микросервисы – это часть СОА. Такая архитектура считается реализацией СОА
Зависимость
Подразделения – зависимы
Они не зависят друг от друга
Размер приложения
Размер приложения больше, чем у обычных программ
Размер приложения всегда небольшой
Стек технологий
Стек технологий ниже, чем у микросервисов
Стек технологий очень большой
Сущность приложения
Монолитная
Полностековая
Независимость и ориентированность
СОА-приложения создаются для выполнения множества бизнес-задач
Создаются для выполнения одной бизнес-задачи
Развертывание
Процесс развертывания растянут по времени
Несложное развертывание, на которое тратится меньше времени
Рентабельность
Более рентабельно
Менее рентабельно
Масштабируемость
Меньше, чем у микросервисов
Высокая масштабируемость
Бизнес-логика
Компоненты бизнес-логики хранятся внутри одного сервисного домена. Простые проводные протоколы (HTTP с XML JSON). API управляется с помощью SDK/клиентов
Бизнес-логика распределена между разными корпоративными доменами
Микросервисные инструменты
Wiremock – тестирование микросервисов
WireMock – это гибкая библиотека для создания заглушек и сервисов-имитаций. В ней можно настроить ответ, который HTTP API вернет при получении определенного запроса. Также может использоваться для тестирования микросервисов.
Docker
Docker – это проект с открытым кодом для создания, развертывания и запуска приложений с помощью контейнеров. Использование такого рода контейнеров позволяет разработчикам запускать приложение в виде одного пакета. Кроме того, в одном пакете могут поставляться библиотеки и другие зависимости.
Hystrix
Hystrix – это отказоустойчивая Java-библиотека. Данный инструмент предназначен для разделения точек доступа к удаленным сервисам, системам и сторонним библиотекам в распределенной среде (микросервисах). Библиотека улучшает всю систему в целом, изолируя неисправные сервисы и предотвращая каскадный эффект от сбоев.
Лучшие примеры использования микросервисной архитектуры
Отдельное хранение данных для каждого микросервиса.
Поддержание кода на едином уровне зрелости
Отдельная сборка для каждого микросервиса.
Заключение
Микросервисы – это СОА-шаблон, в котором приложения создаются как набор малых и независимых серверных единиц.
Микросервисная архитектура относится к стилям разработки архитектуры, позволяющим создавать приложение в виде небольших и автономных сервисов для определенных предметных областей.
Монолитная архитектура похожа на большой контейнер, в котором все компоненты приложения собраны в один пакет.
Каждый блок приложения в микросервисе имеет предельно малый размер и выполняет определенную функцию.
Большая база кода в монолитной архитектуре замедляет процесс разработки. Выход новых версий может растянуться на месяцы. Поддерживать такую базу кода довольно сложно.
Существует 2 типа микросервисов: Stateless (без сохранения состояния) и Stateful (с отслеживанием состояния)
Микросервисы на Java полагаются друг на друга; они должны взаимодействовать между собой. Микросервисы позволяют в большей степени сконцентрироваться на определенных функциях или потребностях бизнеса.
Сервисно-ориентированная архитектура, или СОА, – это усовершенствованные распределенные вычисления, основанные на проектной модели запроса/ответа в синхронных или асинхронных приложениях.
Компоненты приложения в СОА открыты для внешнего мира и представлены в виде сервисов; микросервисы считаются частью СОА. Это реализация СОА.
К популярным микросервисным инструментам относятся Wiremock, Docker и Hystrix.
YUM (Yellowdog Updater, Modified) это менеджер пакетов, используемый в Red Hat, CentOS и других дистрибутивах Linux, использующих RPM Package Manager. Yum используется для установки, обновления, удаления или других манипуляций с пакетами, установленными на этих Linux-системах.
В этом руководстве мы расскажем вам о команде yum update - что она собой представляет, как ее использовать, и о различных командах, которые могут вам пригодиться, для обновления установленных пакетов в вашей системе.
Как работает команда Yum Update?
Yum update - это команда, используемая для обновления приложений, установленных в системе. Если команда выполняется без указания имён пакетов, она обновит все установленные в системе пакеты.
$ yum update
При выполнении этой команды, yum начнёт с проверки своих репозиториев на наличие обновленных версий программного обеспечения, установленных в вашей системе на данный момент. На приведенном ниже Рисунке А показан тип вывода, который вы обычно видите при первом запуске команды yum update.
Как вы можете увидеть,на выводе yum сначала перечисляет запрашиваемые репозитории, которые являются стандартными репозиториями по умолчанию для CentOS: AppStream, Base и Extras.Ниже, приводится список различных пакетов, для которых были найдены обновления.
В конце этого вывода yum отобразит "Сводку транзакций", которая показывает общее количество пакетов, которые должны быть установлены и обновлены.
В данном примере на Рисунке Б, идёт обновление 166 пакетов и установка 6 новых пакетов.
На случай, если вам интересно почему устанавливаются новые пакеты, когда мы должны были только обновить приложения, некоторые новые пакеты программного обеспечения могли стать частью этого дистрибутива Linux, или некоторые обновленные приложения могут полагаться на дополнительные пакеты, которые еще не установлены.
После просмотра списка программного обеспечения, которое yum планирует обновить, вы можете подтвердить эти изменения, набрав "y" и нажав клавишу Enter.
Затем Yum начнёт выполнять обновления, которые могут занять некоторое время в зависимости от скорости вашего соединения и самой системы.
После его завершения вы получите итоговую сводку, как показано на рисунке В, в которой будут перечислены все пакеты, которые были успешно обновлены, а также все ошибки, которые могли возникнуть.
Обновление без проверки gpg
В Linux для проверки подлинности RPM пакетов используются GPG ключи. Если при запуске обычной команды обновления yum вы столкнётесь с ошибкой типа "Package NameOfPackage.rpm is not signed .. install failed!", вы можете с лёгкостью пропустить проверку подлинности RPM пакетов с помощью опции -nogpgcheck.
$ yum update --nogpgcheck
Данный параметр указывает команде yum игнорировать проверку GPG подписей пакетов. И будет полезен в тех случаях, когда у вас есть неподписанный пакет или просто нет ключа GPG.
Обновление из локального репозитория
Можно настроить локальные репозитории для команды yum при выполнении обновлений. Это зачастую делается, если вам нужно использовать yum для обновления пакетов, которые не включены в репозитории по умолчанию, или если вам нужно обновить автономную систему.
Прежде всего, поместите все ваши обновленные RPM-файлы в новую папку. В этом примере мы будем использовать /root/rpms. Затем перейдите в следующую директорию, где вы можете увидеть все файлы репозитория для yum:
$ cd /etc/yum.repos.d
Чтобы настроить собственный репозиторий, создадим новый файл в этом каталоге.
$ vi MyRepo.repo
Непосредственно в вашем repo-файле задайте параметры в указанном формате, меняя строки по мере необходимости:
[MyRepo]
name=My Local Repo
baseurl=file:///root/rpms
enabled=1
gpgcheck=0
Большая разница между локальным и удаленным repo заключается в строке "baseurl", где протокол file:// указывает на локальный файл, в то время как удаленный на протоколы http:// или ftp://.
Как только файл будет сохранен, примените правильные права доступа как показано ниже:
$ chmod 644 MyRepo.repo
Теперь репозиторий может быть готов к использованию. Перед тем, как пытаться выполнить команду yum update убедитесь, что вы очистили кэш yum использую команду:
$ yum clean all
Просмотр обновлений
Yum может отображать доступные обновления безопасности без их установки, с помощью этой команды:
$ yum updateinfo list security
Если в результатах данные не возвращаются, как на рисунке выше, это означает отсутствие обновлений безопасности для всех установленных в вашей системе программных продуктов.
Обновление конкретного пакета
Если вам нужно обновить определенный пакет без запуска обновления для каждого установленного приложения, просто укажите имя пакета в вашей команде yum update.
$ yum update name-of-package
Можно указать несколько пакетов, разделенных пробелом. Вам нужно, чтобы название пакета было указано идеально, чтобы yum смог найти его в своих репозиториях; если вы не уверены в наименовании пакета, сначала проверьте, какие пакеты в настоящее время доступны для обновлений:
$ yum check-update
Обновить все, кроме одного пакета
Если вам нужно выполнить команду yum update, но вы хотите исключить какой-либо пакет из списка обновляемых, вы можете указать опцию -exclude.
Распространённая ситуация, когда администраторы могут счесть это необходимым, связана с обновлениями ядра, так как это основные обновления, которые могут привести к непредсказуемым ошибкам на рабочем сервере. Однако, они всё же могут выполнить команду для обновления менее критичных приложений.
Чтобы исключить пакет (в данном примере связанные с ядром):
$ yum update --exclude=kernel*
Звездочка действует как подстановочный знак, в случае, если существует несколько взаимосвязанных пакетов или вы не знаете полного имени пакета.
В качестве альтернативы:
$ yum update -x 'kernel*'
Исключение нескольких пакетов
Вы можете исключить несколько пакетов с большим количеством опций -exclude.
$ yum update --exclude=kernel* --exclude=httpd
Используйте этот символ, как в примере выше, или же символ -x, столько раз, сколько потребуется.
Проверить, когда было запущено последнее обновление
Для того чтобы увидеть список транзакций с датой и временем их выполнения, воспользуйтесь командой yum history.
$ yum history
На приведенном выше скриншоте, вы можете видеть, что последний раз обновление программного обеспечения yum было 4 января.
Откатить (отменить) обновления
Отличительной особенностью "yum" является то, что она позволяет отменить последнее обновление, тем самым восстанавливая обновленные пакеты до их предыдущих версий.
Каждому действию yum (установка, обновление, удаление и т.д.) присваивается идентификатор транзакции, и этот идентификатор следует указывать при отмене обновления yum.Чтобы посмотреть список идентификаторов операций для недавних действий Yum, воспользуйтесь этой командой:
$ yum history
На скриншоте выше вы можете видеть, что последней операцией, выполненной с помощью yum, была установка пакета httpd. Отмена установки или обновления работает таким же образом, поэтому в этом примере мы отменим последнюю установку httpd. Как показано на скриншоте, эта операция имеет ID 7.
Чтобы отменить это изменение и откатить программу на предыдущую версию, выполните эту команду:
$ yum history undo 7
Как обычно, yum подведёт итоги внесённых изменений и спросит, хотите ли вы продолжить с помощью подсказки Y/N.Если ввести Y, то указанная транзакция будет отменена.
Чистка неудачного обновления Yum
Если не удалось успешно обновить один или несколько пакетов при выполнении команды "yum update", в систему могут быть установлены дубликаты пакетов (2 версии одной и той же программы). Иногда, следуя вышеописанным инструкциям по откату, можно устранить проблему.
Если это не сработает, вы можете удалить дубликаты пакетов вашей системы с помощью данной команды:
$ package-cleanup --dupes
Yum хранит в кэше информацию для пакетов, метаданных и заголовков. Если вы столкнулись с ошибкой,очистка кэш-памяти yum является хорошим первым шагом в устранении неполадок. Для этого используйте следующую команду:
$ yum clean all
Игнорирование ошибок
При обновлении или установке пакета для его корректной работы может потребоваться дополнительное программное обеспечение. Yum знает об этих зависимостях и попытается разрешить их во время обновления, устанавливая или обновляя необходимые дополнительные пакеты.
Если у вас возникнут проблемы с установкой необходимых компонентов, это приведёт к ошибке и не позволит продолжить работу. Это может стать проблемой, если у вас есть другие пакеты, которые необходимо обновить.
Чтобы дать инструкции yum продолжить обновление других пакетов и пропустить пакеты с поврежденными зависимостями, вам следует указать параметр -skip-broken в команде yum update.
$ yum update --skip-broken
Вывести список пакетов, которые нужно обновить.
Выполнение команды Yum update в обычном режиме без дополнительных опций выведет список всех доступных обновлений.
$ yum update
Если вы хотите посмотреть дополнительную информацию о доступных обновлениях пакета, введите эту команду:
$ yum updateinfo
Чтобы посмотреть информацию касательно обновлений безопасности, которые доступны для системы, введите эту команду:
$ yum updateinfo security
Разница между командами yum check update и yum list update
Хотя эти две команды звучат одинаково, но есть разница между проверкой обновлений и списком обновлений в yum.
$ yum list updates
Команда list updates, показанная выше, перечислит все пакеты в репозиториях, для которых доступны обновления. Имейте в виду, что некоторые пакеты в репозиториях могут быть вообще не установлены в вашей системе.
$ yum check-update
Указанная выше команда check-update позволяет проверять наличие обновлений без вмешательства пользователя. Это команда подойдёт в тех случаях, если вы пишите скрипт для проверки обновлений.
Если есть пакеты с доступными обновлениями, команда check-update вернёт значение 100, а если нет доступных обновлений, то значение 0. При обнаружении ошибки возвращается значение 1. Используйте эти значение чтобы надлежащим способом написать свой скрипт.
Уведомление о наличии доступных обновлений
Есть несколько пакетов, которые могут помочь управлять обновлениями yum в вашей системе.Некоторые из них могут даже уведомлять администраторов, если есть обновления, которые можно установить.Один из таких сервисов называется yum-cron.
Для начала установите yum-cron используя yum:
$ yum install yum-cron
Установите службу yum-cron для запуска при загрузке:
$ systemctl enable yum-cron.service
$ systemctl start yum-cron.service
Настройте параметры yum-cron внутри конфигурационного файла с помощью vi или предпочитаемого вами текстового редактора:
$ vi /etc/yum/yum-cron.conf
В этом файле вы можете указать, должны ли обновления применяться автоматически или нет. Если вы хотите только получать уведомления, введите данные электронной почты в файле конфигурации. В любое время, когда появятся обновления для вашей системы, yum-cron отправит вам электронное письмо.
apply_updates = no #don’t apply updates automatically
email_from = root@localhost
email_to = admin@example.com
email_host = localhost
Какой порт использует yum update
При проверке обновлений yum использует порт 80. Если вы загляните внутрь файлов репозитория в вашей системе, то вы увидите, что все ссылки внутри начинаются с http. Таким образом, для нормального функционирования yum на брандмауэре нужно прописать правило и открыть порт 80.
Yum update против upgrade
До сих пор в этом руководстве мы говорили только о команде yum update, но есть и другая очень похожая команда: yum upgrade.
$ yum upgrade
Существует небольшая разница между этими двумя командами. Yum update обновит пакеты в системе, но пропустит удаление устаревших пакетов. Yum upgrade тоже обновит все пакеты в вашей системе, но также удалит устаревшие пакеты.
Это по своей сути более безопасный вариант команды yum update, поскольку вам не нужно беспокоиться о случайном удалении необходимого пакета при обновлении программного обеспечения.
Будьте внимательны при вводе команды yum upgrade, так как она может не сохранить некоторые пакеты, которые вы всё ещё используете. Я надеюсь, что вы найдете это руководство полезным при работе с утилитой yum.
О переходе в IT профессию не думал разве только тот, кто в IT сфере уже работает. Высокие зарплаты, постоянная удаленка, куча плюшек и битвы HR-ов за самый оригинальный подкат к айтишнику на LinkedIn. Насмотревшись на фотографии и рассказы друзей айтишников, все это заставляет многих подумать: а не пора ли сменить профессию? Если задумались - значит пора. А мы, в свою очередь, поможем разобраться, какие бывают айтишники и как вам войти в айти.
Говоря про айтишников, многие представляют себе программистов, их еще называют девелоперы (от английского developer) или разработчики. Но поверьте, айти не заканчивается на них, а скорее только начинается. Разновидностей программистов - как товаров на Amazon: frontend, backend, full-stack, веб-программисты, мобильные и десктоп разработчики, DevOps программисты и прочие.
Особенно важно разобраться с тремя первыми - фронт, бэк, и фуллстэк.
Понять разницу между фронтэнд и бэкэнд девелопером - ну очень просто. Фронтенд пишет все, что происходит в видимой зоне, а бэкенд - за видимой зоной. Сейчас разберемся на конкретных примерах:
Netflix: красивую картинку с палитрой интересных киношек, кнопки, слайдеры и все, что вы видите в видимой зоне - сделали фронты. Алгоритмы рекомендаций, авторизацию, списание денег с вашей карты, то есть биллинг, и другие компоненты на фоне - сделали бэкенд девелоперы. Когда в следующий раз будете реветь от рекомендаций мелодрамы, которая ранила вас прямо в сердечко - это бэки постарались.
Amazon: карточки товаров, категории, навигация, отзывы и прочая визуальщина - фронты. Передача на на фронт актуальных цен товаров, калькуляция условий доставки в ваш регион мешка с леденцами со вкусом корицы, механизм умного поиска - бэки.
А еще есть фуллстэк программисты - это те, кто умеют и бэк и фронт.
В среднем, чтобы стать фронтом, надо поучить HTML, CSS, JavaScript - это база, с которой уже можно верстать сайты. Но технологии не стоят на месте и сейчас зачастую обычного знания JavaScript бывает недостаточно, поскольку во многих местах используются различные фреймворки расширяющие функционал языка, такие как React, Angular или Vue.
Ну а поскольку разработчик всегда работает с командой, то нужно знать как работать с системами управления версиями, зачастую это Git и уметь работать с API, чтобы найти общий язык с бэкэнд.
Бэкенд девелоперу, очевидно, нужно знать один из языков программирования для бэка. Какой? Вам нужно определиться самому. Посмотрите вакансии, которые вас интересуют и поймите, что нужно в компании вашей мечты.
Самые известные и популярные языки это Java, Python, PHP, С, С#, С++, Ruby и Go. Их очень много, но не стоит отчаиваться глядя на их количество - изучив один язык и поняв принципы программирования, вы сможете легко перейти на другой язык.
Еще можно выделить мобильных разработчиков, которые делают приложения для iOS и Android - им нужно подучить Objective-C и Swift для iOS и Kotlin или Java для андроида.
Поскольку разработчики пишут код не в вакууме, а взаимодействуют с различными системами, то вам нужно знать про SQL и принципы работы с базами данных. И очень важно уметь работать с NoSQL - нереляционными базами. Если хочешь заниматься только базами то для этого даже есть отдельная профессия - администратор баз данных (DBA).
Если вы будете заниматься веб разработкой, то нужно знать про принципы работы HTTP и про модель OSI, про веб сервера, как минимум Apache и Nginx, как работают API, аутентификация, основы безопасности. Уф, ну кажется этого должно хватить для начала.
Идем дальше - тестировщики, а они же QA (Quality Assurance). Тестирование бывает ручное, а бывает автоматическое. Автоматизаторы, безусловно, ближе к программистам - им нужно разрабатывать алгоритмы, знать процессы разработки ПО и его тестирования.
В ручном тестировании - все немного попроще. Зачастую тестирование становится отправной точкой для карьеры будущего айтишника. Входной билет сюда чуть ниже, войти проще. Нужно знать классификацию тестирования, методы и инструменты, уметь создавать сценарии тестирования. Нужно базово понимать протокол HTTP и модель OSI, немного HTML и CSS. Хорошо бы уметь работать с командной строкой, знать SQL, принципы API чтобы гонять запросы в каком-нибудь клиенте типа Postman, знать инструменты автоматического тестирования, такие как Selenium или Sahi.
Уф, кажется, основные профессии, связанные напрямую с разработкой софта мы проговорили. Теперь, друг, давай разберемся с не менее крутой частью IT, где ощущается острейший дефицит кадров - это инфраструктурные айтишники.
Итак, сетевые инженеры - без них не “взлетит” ни одно приложение, сервис, сайт, платформа, да что угодно! Сетевики настраивают маршрутизацию трафика, управляют сетью и гарантируют взаимодействие айти - инфраструктуры с внешними сетями. Открывая Tinder, каждый свайп вправо генерирует запрос к серверам, который прилетает в дата - центр тиндера и маршрутизируется на нужный сервер - это как раз сетевик постарался.
Сетевик должен знать основы сетевых технологий - классической школой в этом плане являются технологии Cisco (а также Huawei, Juniper и Mikrotik), надо знать технологии виртуализации, уметь работать с операционными системами Linux и Windows Server, иметь представления о кибербезопасности и уметь читать и базово говорить по английски.
И конечно безопасники - про их востребованность сейчас, вы наверняка догадываетесь. Среди них выделяют:
Инженеров - эти ребята делают безопасной сеть, настраивают фаерволы, антивирусы, анти-DDoS, прокси и прочие средства защиты
Аналитиков - которые выявляют инциденты, мониторят и находят вредоносную активность, расследуют взломы, утечки и другие неприятные моменты
Пентестеров - это HackerMan’ы по найму. Ага, эти ребята занимаются легитимным взломом, чтобы потом вы могли закрыть все дырки обнаруженные ими и не стать жертвой настоящих хакеров
Консультантов - знают все законы и требования в ИБ, помогут в получении нужных бумаг, чтобы не попасть на штрафники от всяких регуляторов
Appsec, Cloudsec - занимаются безопасностью приложений и облачной инфраструктуры
В компаниях постоянно идут эпические битвы между айтишниками и ИБшниками, потому что последние, довольно параноидальные ребята. Они стараются максимально обезопасить инфраструктуру и её активы, вводя для этого различные правила. Например - хочешь подключиться к корпоративному VPN? Сначала пройди двухфакторную аутентификацию! Долго? Зато безопасно.
Для безопасника будет полезно понимать основы сетевой безопасности, а также операционных систем, знать что такое триада CIA и принцип Defense in Depth, ну и конечно же - знать какие существуют методы атак, вредоносного ПО и прочих ИБ угроз.
Так же есть более узкопрофильные направления - Linux или Windows администратор, специалист по IP - телефонии, администратор баз данных, SRE инженер и многие другие! Ну и конечно можно наоборот выделить широкопрофильного системного администратора - специалиста, который настраивает и поддерживает ИТ инфраструктуру компании и должен знать много вещей из разных областей.
Так, кажется большинство популярных технических направлений мы проговорили. Теперь давайте прыгнем к менеджерам, тем, кто управляет ИТ проектами и продуктами с точки зрения бизнеса. Вообще, скажем так, быть техно - коммерческим специалистом в айти отрасли ну крайне выгодно: комбинируя хороший технический бэкграунд, знание бизнес специфики, добавив высокие коммуникативные навыки и надев белую рубашку вы автоматически получаете высочайшую зарплату, корпоративную тачку и прочие радости. Ладно, шутка, давайте разбираться.
Продакт менеджеры (они же продакты) - эти ребята отвечают за коммерческий успех продукта и реализацию бизнес требований. Продакт знает такие фреймворки как Scrum и Agile, должен знать цикл разработки программного обеспечения, отвечать за список задач на разработку, который также называют “бэклог” и обязательно уметь говорить на одном языке с разработчиками, топ-менеджментом, продавцами, маркетингом и другими подразделениями компании. Пожалуй, продакт должен знать такие инструменты как JIRA, Trello, Miro, Slack и Wrike, и уметь анализировать метрики успеха продукта.
Если хотите двигаться в это направление, рекомендуем получить интересующие вас технические навыки, а потом двигать в бизнес плоскость - почитать Lean Startup, “Спросите маму” Роберта Фитцпатрика и про Scrum у Джеффа Сазерленда. Эти книги помогут вам базово сориентироваться в пространстве и получить базовое представление.
Проектные менеджеры, они же delivery менеджеры - они отвечают за реализацию проекта - контроль сроков, доставку функций продукта в продакшн, то есть в реальную среду работы продукта, отвечают за организацию человеческих ресурсов и планирование, в том числе релизов. Из хард скиллов вам надо знать что такое "Диаграмма Ганта", изучите свод знаний по управлению проектами PMBOK, который разработан американским Институтом управления проектами (PMI), знать гибкие методологии и уметь работать с теми же инструментами, что и продакту (JIRA, Trello, Miro, Slack и Wrike).
А еще есть UX - дизайнеры, продуктовые дизайнеры, аналитики, но они имеют менее технический уклон, чем продакты и проджекты.
Познать востреброванные айти профессии, получая знания в легкой и дружелюбной форме можно с помощью нашей платформы доступного айти образования Merion Academy: ознакомиться со списком курсов и пройти бесплатные вводные уроки можно по этой ссылке.