Всем привет, мы в Айтишном Поиске. В прошлой статье мы говорили о программистских IT-специальностях. Без долгих предисловий, давайте продолжим разговор: на этот раз о специальностях в других областях IT.

Вокруг процесса создания программного продукта есть много технических задач, помимо непосредственно написания кода. Могут ли этими задачами заниматься сами программисты, которых мы обсудили в предыдущем выпуске?

Могут, и более того, лет 20 назад они этим всем и занимались. На ум приходит аналогия с земским врачом 19-го века, который один занимался здоровьем своих десятков тысяч подопечных в округе. Однако, с развитием медицины, вместо одного врача-универсала, появились свои хирурги, дантисты и ортопеды.

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

Тестирование — это процесс проверки программного обеспечения на соответствие требованиям и выявление ошибок (“багов”).

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

Модульное тестирование (“Unit testing” или “юнит”), когда проверяются результаты исполнения отдельных блоков кода внутри программы и интеграционное тестирование (“Integration testing”), когда проверяется взаимодействие различных частей программы друг с другом.

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

Но важно проверять не только то, что программа делает правильно, но и то, что она может делать неожиданно и/или ошибочно.

Даже в простых программах - огромная комбинаторика взаимодейстия с ними (в калькуляторе, например, нажать 5 кнопок можно тремя миллионами разных последовательностей).

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

Тестирование бывает мануальным/ручным и автоматизированным. Первое - когда человек сам проверяет работу программы; второе - когда для этого используются специальные программы (автотесты - это, по сути, программы, написанные вокруг целевого продукта и проверяюшие его на соответствие требованиям и отсутствие ошибок).

Такие тесты пишут либо сами программисты, либо отдельные специалисты - автоматизаторы тестирования (“Test Automation Engineers”). Ручной тестировщик может набраться опыта и, со временем, перейти в автоматизированное тестирование.

У ручного и автотестирования есть свои плюсы и минусы: ручное требует постоянного вовлечения работника в каждую итерацию тестирования, но вместе с тем более гибкое, так как человек может быстрее адаптироваться к смене требований; автотесты нужно сначала написать, а потом поддерживать и дописывать, но готовые автотесты ускоряют каждую итерацию тестирования и позволяют освободить время тестировщиков под другие нужды.

QA - значит Quality Assurance - контроль и обеспечение качества. Тестирование, о котором мы только что говорили, - это один из инструментов QA.

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

QA могут влиять и на сам процесс разработки, контролируя соотвествие стандартам и следование лучшим практикам.

Обычно, QA становятся тестировщики, которые набираются опыта и навыков и хотят продвинуться по карьерному пути.

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

DevOps переводится как Development & Operations - это концепция синтеза разработки ПО (Development) и управления и обслуживания IT-инфраструктуры (Operations).

Про Development сферу мы уже говорили - в ней находятся программисты; в сфере IT Operations раньше традиционно располагались системные администраторы, сисадмины (= Те самые мифические бородачи в свитерах с оленями, занимавшиеся всеми аспектами IT, кроме работы над программными продуктами).

Разделение на Development и Operations существовало много лет, так почему вдруг появляется смежная область?

С одной стороны, многие аспекты Operations стали проще - теперь вместо закупки и настройки реального оборудования, можно создать готовый к работе виртуальный сервер в пару кликов мыши.

Да и доступ к знаниям (например, о настройке Linux) упростился с развитием интернета, поисковиков и сообществ типа StackOverflow.

С другой стороны, процесс разработки ПО стал сложнее, и к нему в целом предъявляются более высокие требования: программистам надо думать о слиянии (“merge” - одна из краеугольных концепций совместной работы над кодом) своего кода, с кодом, написанным их коллегами; компиляции под различные архитектуры процессоров; прохождении авто-тестов; выкатке готовых программ на сервера.

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

IT-инфраструктура и сама сфера разработки ПО были поставлены перед новыми вызовами, например: какую пиковую нагрузку может выдерживать система, или насколько быстро новая фича станет доступна пользователям?

Раньше доставка обновления могла занимать полгода, теперь, в грамотно настроенных системах, - считанные дни, или даже часы.

Это всё называется термином (Continuous Integration / Continuous Delivery) - непрерывная интеграция и непрерывная доставка, и является одним из столпов DevOps.

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

С появлением возможности запускать написанные программы в универсальных Docker-контейнерах, вскоре потребовалось уже тонко настраивать и управлять группами этих контейнеров, - появилась система Kubernetes - еще один из столпов DevOps.

С распространением облачных сервисов и виртуальных серверных машин, появились и новые инструменты управления этими серверами и инфраструктурой в целом - такие как Ansible и Terraform: призванные облегчить решение IT-задач, они в тоже время создали новые рабочие места для DevOps.

SRE переводится как Site Reliability Engineering, и значит “Создание и поддержка надежных и устойчивых IT-систем”. Эта специальность во многом переплетена и связана с DevOps примерно так же, как QA связан с тестированием.

Основные цели SRE - помимо перечисленного в DevOps - это обеспечение надежности функционирования IT-инфраструктуры.

Это достигается многими методами, включая сбор и анализ метрик, мониторинг систем, расследование инцидентов.

Про SRE написаны очень хорошие книги, с первой такой (Site Reliability Engineering: How Google Runs Production Systems (2016)), выпущенной инженерами Гугл, эта специальность и появилась.

В чем-чем, а в поддержке самых масштабных и высоконагруженных сервисов в мире у Гугла первоклассный опыт.

Так что, с одной стороны, SRE - одна из престижных специальностей, венец технической карьеры по DevOps направлению, но требующая колоссальных объемов знаний и навыков.

С другой стороны - все знания находятся в открытом доступе, большинство используемого инструментария - OpenSource. Вопрос только во времени и дисциплине при обучении.

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

Если вам нравится в Айтишном Поиске - подписывайтесь на наш Ютуб и Телеграмм каналы:

YouTube

Telegram

До встречи!