Всем привет, мы в Айтишном Поиске. В прошлой статье мы говорили о программистских IT-специальностях.
Без долгих предисловий, давайте продолжим разговор: на этот раз о специальностях в других областях IT.
Сопровождение
Вокруг процесса создания программного продукта есть много технических
задач, помимо непосредственно написания кода. Могут ли этими задачами
заниматься сами программисты, которых мы обсудили в предыдущем выпуске?
Могут, и более того, лет 20 назад они этим всем и занимались. На ум
приходит аналогия с земским врачом 19-го века, который один занимался
здоровьем своих десятков тысяч подопечных в округе.
Однако, с развитием медицины, вместо одного врача-универсала, появились
свои хирурги, дантисты и ортопеды.
Технологии усложняются, поэтому целесообразнее стало готовить
специалиста для каждой конкретной специальности для достижения
наибольшей результативности.
Сопровождение программного обеспечения включает в себя поддержание
его работоспособности, обновление и устранение ошибок.
Специалисты, занимающиеся сопровождением, выполняют задачи по
мониторингу работы системы, анализу отзывов пользователей и устранению выявленных проблем.
Тестирование
Тестирование — это процесс проверки программного обеспечения на соответствие требованиям и выявление ошибок (“багов”).
В правильно построенном процессе разработки ПО, программисты тоже участвуют в тестировании. Но есть такая концепция, как пирамида тестирования, и программистам там, обычно, отведены нижние уровни.
Модульное тестирование (“Unit testing” или “юнит”), когда проверяются результаты исполнения отдельных блоков кода внутри программы и интеграционное тестирование (“Integration testing”), когда проверяется взаимодействие различных частей программы друг с другом.
На более высоких уровнях пирамиды тестирования решается уже вопрос о
том, соответствует ли программа требованиям (то есть: решает ли она те
задачи, ради которых создавалась).
Но важно проверять не только то, что программа делает правильно, но и то, что она может делать неожиданно и/или ошибочно.
Даже в простых программах - огромная комбинаторика взаимодейстия с
ними (в калькуляторе, например, нажать 5 кнопок можно тремя миллионами
разных последовательностей).
Поэтому тестировщикам желательно разбираться не только в
тестировании, но и в программировании, чтобы понимать, где потенциальные
проблемы искать в первую очередь.
Тестирование бывает мануальным/ручным и автоматизированным. Первое - когда человек сам проверяет работу программы; второе - когда для этого используются специальные программы (автотесты - это, по сути, программы, написанные вокруг целевого продукта и проверяюшие его на соответствие требованиям и отсутствие ошибок).
Такие тесты пишут либо сами программисты, либо отдельные специалисты - автоматизаторы тестирования (“Test Automation Engineers”).
Ручной тестировщик может набраться опыта и, со временем, перейти в автоматизированное тестирование.
У ручного и автотестирования есть свои плюсы и минусы: ручное требует постоянного вовлечения работника в каждую итерацию тестирования, но вместе с тем более гибкое, так как человек может быстрее адаптироваться к смене требований; автотесты нужно сначала написать, а потом поддерживать и дописывать, но готовые автотесты ускоряют каждую итерацию тестирования и позволяют освободить время тестировщиков под другие нужды.
QA
QA - значит Quality Assurance - контроль и обеспечение качества.
Тестирование, о котором мы только что говорили, - это один из инструментов QA.
QA-инженеры берут на себя больше ответственности, потому что их цель -
обеспечение качества продукта - масштабнее, чем просто проверка работы
фич и поиск багов. QA вступают в процесс разработки ПО раньше тестировщиков, зачастую, еще на этапе анализа технического задания, так как создание непротиворечивых и реалистичных требований к продукту -
большая инвестиция в его будущее качество.
QA могут влиять и на сам процесс разработки, контролируя соотвествие
стандартам и следование лучшим практикам.
Обычно, QA становятся тестировщики, которые набираются опыта и
навыков и хотят продвинуться по карьерному пути.
Надо отметить, что в некоторых компаниях позиции тестировщиков и QA
отсутствуют, а сами задачи, по сути, возложены на разработчиков.
В какой-то мере это является шагом назад, к миру программистов-универсалов, более простой модели с организационной точки
зрения, но предъявляющей более высокие требования к каждому конкретному разработчику.
DevOps
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
SRE переводится как Site Reliability Engineering, и значит “Создание и поддержка надежных и устойчивых IT-систем”.
Эта специальность во многом переплетена и связана с DevOps примерно так же, как QA связан с тестированием.
Основные цели SRE - помимо перечисленного в DevOps - это обеспечение надежности функционирования IT-инфраструктуры.
Это достигается многими методами, включая сбор и анализ метрик, мониторинг систем, расследование инцидентов.
Про SRE написаны очень хорошие книги, с первой такой (Site Reliability Engineering: How Google Runs Production Systems (2016)), выпущенной инженерами Гугл, эта специальность и появилась.
В чем-чем, а в поддержке самых масштабных и высоконагруженных сервисов в мире у Гугла первоклассный опыт.
Так что, с одной стороны, SRE - одна из престижных специальностей, венец технической карьеры по DevOps направлению, но требующая колоссальных объемов знаний и навыков.
С другой стороны - все знания находятся в открытом доступе, большинство
используемого инструментария - OpenSource. Вопрос только во времени и дисциплине при обучении.
Так уж вышло, что одной статьей по теме “Cопровождение” ограничиться
не получится (чтобы не перегрузиться количеством информации и букв),
поэтому ожидайте следующую.
Если вам нравится в Айтишном Поиске - подписывайтесь на наш Ютуб и Телеграмм каналы:
До встречи в следующем выпуске!