Девопс синоним

Материал из CDTOwiki

Перейти к: навигация, поиск

Трудно уловить главное, говоря о DevOps? Мы собрали для вас яркие аналогии, ударные формулировки и советы от экспертов, которые помогут дойти до сути даже неспециалистам. В конце бонус – собственный DevOps сотрудников Red Hat.

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

Поэтому про DevOps нередко можно услышать вопросы вроде, это то же самое, что agile? Или это какая-то особая методология? Или это просто еще один синоним слова «сотрудничество»?

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

Что такое DevOps: 6 определений и аналогий

Мы попросили специалистов объяснить суть DevOps максимально просто и коротко, чтобы ее ценность стала понятна читателю с любым уровнем технической подготовки. По итогам этих бесед мы отобрали самые яркие аналогии и ударные формулировки, которые помогут вам выстроить свой рассказ о DevOps.

1. DevOps – это культурное движение

«DevOps – это культурное движение, в рамках которого обе стороны (разработчики ПО и специалисты по эксплуатации ИТ-систем) признают, что софт не приносит реальной пользы до тех пор, пока им не начинает кто-то пользоваться: заказчики, клиенты, сотрудники, не суть, – считает Эвелина Эрлих (Eveline Oehrlich) старший аналитик-исследователь Института DevOps. – Поэтому обе эти стороны совместно обеспечивают быструю и качественную доставку софта».

2. DevOps – это то, что наделяет властью разработчиков

«DevOps наделяет разработчиков полномочиями на владение приложениями, их запуск и управление доставкой от начала и до конца»

«Обычно о DevOps говорят, как о способе ускорить доставку приложений в продакшн за счет выстраивания и применения автоматизированных процессов, – говорит Джей Шнайп (Jai Schniepp), директор по платформам DevOps страховой компании Liberty Mutual. – Но для меня это гораздо более фундаментальная вещь. DevOps наделяет разработчиков полномочиями на владение приложениями или определенными частями ПО, на их запуск и управление доставкой от начала и до конца. DevOps устраняет неразбериху с ответственностью и ведет всех участников процесса к созданию автоматизированной и управляемой разработчиком инфраструктуры».

3. DevOps – это сотрудничество при создании и доставке приложений

«Проще говоря, DevOps – это такой подход к производству и доставке ПО, когда все работают вместе», – отмечает Гур Стаф, президент и руководитель направления автоматизации цифрового бизнеса компании BMC.

4. DevOps – это конвейер

«Конвейерная сборка возможна, только если все детали подходят друг к другу».

«Я бы сравнил DevOps с конвейером по сборке автомобилей, – продолжает Гур Стаф. – Идея в том, чтобы заранее спроектировать и сделать все детали так, чтобы потом их можно было собрать без индивидуальной подгонки. Конвейерная сборка возможна, только если все детали подходят друг к другу. Те, кто проектирует и делает двигатель, должны подумать о том, как крепить его к кузову или раме. Те, кто делает тормоза, должны подумать о колесах, и так далее. Точно так же должно быть и с софтом.

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

«Сделать так, чтобы люди сотрудничали и думали о тех частях работы, которые выполняются другими, а не концентрировались исключительно на своих собственных задачах – вот величайшее препятствие, которое надо преодолеть. Если это удается, у вас появляются отличные шансы на цифровую трансформацию», – добавляет Гур Стаф.

5. DevOps – это правильная комбинация людей, процессов и автоматизация

Джейн Гролл (Jayne Groll), исполнительный директор Института DevOps, предложила отличную аналогию для объяснения DevOps. По ее словам, «DevOps – это как кулинарный рецепт, в котором есть три основные категории ингредиентов: люди, процессы и автоматизация. Большинство этих ингредиентов можно взять из других областей и источников: Lean, Agile, SRE, CI/CD, ITIL, лидерство, культура, инструменты. Секрет DevOps, как и любого хорошего рецепта, в том, как правильно подобрать пропорции и смешать эти ингредиенты, чтобы повысить скорость и результативность работы при создании и выпуске приложений».

6. DevOps – это когда программисты работают, как команда Формулы-1

«Гонка планируется не от старта к финишу, а наоборот, от финиша к старту».

«Говоря о том, чего ждать от инициативы DevOps, я привожу в пример гоночную команду NASCAR или Формулы-1, – говорит Крис Шорт (Chris Short), главный менеджер по маркетингу облачных платформ Red Hat и издатель рассылки DevOps’ish. – У руководителя такой команды одна цель: занять по итогам гонки максимально возможное место с учетом имевшихся у команды ресурсов и выпавших на ее долю испытаний. При этом гонка планируется не от старта к финишу, а наоборот, от финиша к старту. Вначале ставится амбициозная цель, а затем определяются пути ее достижения. После чего они разбиваются на подзадачи и делегируются членам команды».

«Всю неделю перед гонкой команда оттачивает пит-стоп. Занимается силовыми и кардиотренировками, чтобы быть в форме в изнурительный день гонок. Отрабатывает совместные действия при решении любых проблем, которые могут возникнуть на гонке. Аналогично команда разработчиков должна тренировать навыки частого выпуска новых версий. При наличии таких навыков и отлаженной системы безопасности запуск новых версий в продакшн тоже происходит чаще. В рамках этого мировоззрения рост скорости означает рост безопасности», – говорит Шорт.

«Дело не в том, чтобы делать «правильные вещи», – добавляет Шорт, – а в том, чтобы устранять как можно больше вещей, которые стоят на пути к желаемому результату. Сотрудничайте и адаптируйтесь с учетом обратной связи, которую вы получаете в реальном времени. Будьте готовы к аномалиям и работайте над повышением качества, чтобы свести к минимуму их влияние на движение к цели. Именно это ожидает нас в мире DevOps».

Как масштабировать DevOps: 10 советов от экспертов

Просто DevOps и массовый DevOps – это абсолютно разные вещи. Мы расскажем, как преодолеть барьеры на пути от первого ко второму.

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

Увы, это лишь фальшивый блеск, иллюзия прогресса, как говорит Бен Гриннел (Ben Grinnell), управляющий директор и руководитель направления цифровых технологий консалтинговой фирмы North Highland. Ранние победы конечно обнадеживают, но не помогают достичь конечной цели, а именно, массового использования DevOps в организации.

Легко видеть, что в результате формируется культура разделения на «мы» и «они».

«Зачастую организации запускают такие проекты-первопроходцы, считая, что они проложат путь к массовому DevOps, не задумываясь, смогут и захотят ли пойти этим путем остальные, – объясняет Бен Гриннел. – Команды для реализации таких проектов обычно набирают из самоуверенных “варягов”, которые уже делали нечто подобное в других местах, но являются новичками в вашей организации. При этом их поощряют ломать и разрушать правила, которые остаются обязательными для всех остальных. Легко видеть, что в результате формируется культура разделения на «мы» и «они», которая препятствует передаче знаний и навыков».

«И эта культурная проблема – лишь одна из причин того, что DevOps сложно масштабировать. Команды DevOps сталкиваются с ростом сугубо технических сложностей, характерным для быстроразвивающихся компаний, сделавших ставку на ИТ-технологии», – говорит Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr.

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

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

1. Помните, что для изменений в культуре нужно время

Джейн Гролл (Jayne Groll), исполнительный директор Института DevOps: «На мой взгляд, расширение DevOps должно быть таким же постепенным и итеративным, как и agile-разработка (и в равной мере затрагивать культуру). В Agile и DevOps упор делается на небольшие команды. Но по мере роста числа и интеграции таких команд мы получаем все больше людей, применяющих новые методы работы, и, как следствие, возникает масштабная культурная трансформация».

2. Уделите достаточно времени планированию и выбору платформы

Эран Кинсбрюнер (Eran Kinsbruner), ведущий технический евангелист компании Perfecto: «Чтобы масштабирование сработало, командам DevOps в начале надо научиться сочетать традиционные процессы, инструменты и навыки, а затем медленно взращивать каждую отдельную фазу DevOps и стабилизировать ее. Все начинается с тщательного планирования пользовательских историй (userstory) и потоков создания ценности (valuestream), после чего наступает этап написания ПО и контроля версий с использованием trunk-based development или других подходов, наиболее подходящих для ветвления и слияние кода».

«Затем следует этап интеграции и тестирования, где уже требуется масштабируемая платформа для автоматизации. И здесь командам DevOps важно выбрать правильную платформу, которая отвечала бы их уровню навыков и конечным целям проекта.

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

3. Избавьте ответственности от привкуса вины

Гордон Хафф (Gordon Haff), евангелист RedHat: «Создание системы и атмосферы, разрешающей и поощряющей эксперименты, позволяет реализовать так называемые успешные сбои в agile-разработке ПО. Это не значит, что за сбои больше никто не отвечает. На самом деле установить ответственного становится даже проще, поскольку «быть ответственным» больше не означает «стать виновником аварии». То есть суть ответственности качественно меняется. При этом крайне важными становятся четыре фактора: масштабы сбоя, подходы, производственные процессы и стимулы». (Подробнее об этих факторах можно прочитать в статье Гордона Хаффа «DevOps lessons: 4 aspects of healthy experiments».)

4. Расчищайте путь вперед

Бен Гриннел (Ben Grinnell), управляющий директор и руководитель направления цифровых технологий консалтинговой фирмы North Highland: «Чтобы добиться масштабирования, я рекомендую вместе с проектами-первопроходцами запускать программу «расчистки пути». Цель этой программы – убирать мусор, который остается за первопроходцами DevOps, вроде потерявших актуальность правил и прочих подобных вещей, чтобы путь вперед оставался свободен».

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

5. Сделайте инструменты более демократичными

Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: «Инструменты не надо прятать от людей, и они должны быть относительно просты в освоении для любого, кто готов потратить на это время. Если возможность запрашивать логи предоставлена только трем людям, «сертифицированным» для работы с каким-то инструментом, у вас всегда будет максимум три человека, способных разобраться с соответствующей проблемой, даже если у вас очень большая вычислительная среда. Иначе говоря, здесь возникает узкое место, которое может привести к серьезным (для бизнеса) последствиям».

6. Создайте идеальные условия для работы команды

Том Кларк (Tom Clark), руководитель направления Common Platform в телекомпании ITV: «Вы можете сделать что угодно, но не все сразу. Поэтому ставьте большие цели, начинайте с малого и двигайтесь вперед быстрыми итерациями. Со временем вы заработаете репутацию команды, у которой все получается, поэтому другие тоже захотят использовать ваши методы. И не гонитесь за выстраиванием высокоэффективной команды. Вместо этого обеспечьте людям идеальные условия для работы и эффективность придет сама собой».

7. Не забывайте о законе Конвея и канбан-досках

Логан Дейгл (Logan Daigle), директор по доставке ПО и стратегии DevOps компании CollabNetVersionOne: «Важно осознавать последствия закона Конвея. В моем вольном пересказе этот закон гласит, что продукты, которые мы создаем, и процессы, которые мы при этом используем, включая DevOps, оказываются устроены так же, как и наша организация».

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

«Еще один важный аспект масштабирования заключается в том, чтобы отображать на канбан-досках все работы, находящиеся в процессе выполнения (WIP, workinprogress). Когда в организации появляется место, где люди могут видеть такие вещи, это сильно стимулирует сотрудничество, что положительно сказывается на масштабировании».

8. Ищите старые шрамы

Манюэль Паис (Manuel Pais), консультант по DevOps и соавтор книги «Team Topologies»: «Вывод практик DevOps за пределы собственно Devи Opsи попытку применить их к другим функциям вряд ли можно назвать оптимальным подходом. Это, несомненно, даст определенный эффект (например, за счет автоматизации ручного управления), но можно добиться гораздо большего, если начать с понимания процессов доставки и обратной связи».

«Если в ИТ-системе организации есть старые шрамы – процедуры и механизмы управления, которые были внедрены по итогам прошлых инцидентов, но утратили актуальность (из-за смены продуктов, технологий или процессов), – то их, безусловно, надо удалять или разглаживать, а не автоматизировать неэффективные или ненужные процессы».

9. Не плодите варианты DevOps

Энтони Эдвардс (Antony Edwards), директор по производству компании Eggplant: «DevOps – очень расплывчатый термин, поэтому у каждой команды получается свой вариантDevOps. И нет ничего хуже, когда в организации появляются сразу 20 разновидностейDevOps, которые не очень хорошо уживаются вместе. Нельзя, чтобы у каждой из трех команды разработчиков был свой, особый интерфейсом между разработкой и управлением продуктом. Как и нельзя, чтобы продукты имели свои, уникальные ожидания в части обработки обратной связи при переносе в симулятор производственной среды. Иначе у вас никогда не получиться масштабироватьDevOps».

10. Проповедуйте ценность DevOps для бизнеса

Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: «Поработайте над признанием ценности DevOps. Научитесь и не стесняйтесь рассказывать о пользе того, что вы делаете. DevOps невероятно экономит время и деньги (просто подумайте: меньше простоев, короче среднее время восстановления), и команды DevOps должны неустанно подчеркивать (и проповедовать) важность этих инициатив для успеха бизнеса. Так вы сможете расширить круг адептов и усилить влияние DevOps в организации».

БОНУС

На Red Hat Forum Russia 13 сентября прилетит наш собственный DevOps – да, у Red Hat, как у производителя программного обеспечения, есть собственные DevOps команды и практики.

Наш инженер Марк Биргер, который занимается разработкой служб внутренней автоматизации для других групп по всей организации, на чистом русском языке расскажет собственную историю – как DevOps команда Red Hat мигрировала приложения из виртуальных сред Hat Virtualization, управляемых Ansible в полноценный контейнерный формат на платформе OpenShift.

Но и это еще не все:

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

Недавно принятые поправки в закон «О государственном языке Российской Федерации» заставили нас задуматься о том, как заменить англоязычные термины русскими синонимами. Но как же выразиться, когда нет подходящего слова на родном языке? В этой статье, команда Joy Dev, рассмотрим более 100 слов и фраз, используемых IT-специалистами, и предложим альтернативы на русском языке.

Содержание

А-К

1. Адепты (англ. ”adept”) — опытные разработчики или эксперты, имеющие широкий кругозор в определённой области. Также этот термин может использоваться для обозначения энтузиастов, которые активно изучают и практикуют новые технологии и языки программирования. Пример употребления: «Этот программист является настоящим адептом веб-разработки и имеет огромный опыт в создании качественных сайтов». Аналог на русском — “знаток”, “специалист”.

2. Аналитить — означает анализировать, исследовать, изучать. Пример употребления: «Мы должны постоянно аналитить данные, чтобы понимать поведение наших пользователей». Аналог на русском — “анализировать”.

3. Апдейт (англ. «update») — обновление, изменение данных или программного обеспечения. Пример употребления: «Сейчас мы работаем над апдейтом системы для улучшения её производительности». Аналог на русском — “обновление”.

4. Апишка (c англ. «API») — это интерфейс программирования приложений, который используется для взаимодействия между различными приложениями или сервисами. Пример употребления: «Мы используем апишку Google Maps, чтобы интегрировать карты в наше приложение».

5. Апрув (англ. “approve”) — одобрение или подтверждение. Пример употребления: Я должен получить апрув от менеджера, прежде чем выпустить новую версию приложения”. Аналог на русском — ”подтверждение”.

6. Артефакт — результат работы программиста, например, скомпилированный файл, собранный пакет, документация или другие материалы. Пример употребления: «На сервере оказался ненужный артефакт, который занимал слишком много места». Аналог на русском — “результат работы”.

7. Асайн (англ. “assign”) — назначение кого-то на какую-то задачу или проект. Пример употребления: «Я только что асайнул тебя на новую задачу, проверь свой емейл». Аналог на русском— “назначение”.

8. Ассемблер (англ. «assembler») — язык программирования, близкий к машинному коду, использующийся для написания низкоуровневого кода. Пример употребления: «Нам нужен специалист по ассемблеру для оптимизации кода».

9. Баг (англ. “bug”) — ошибка в программном обеспечении, которая приводит к непредсказуемому поведению. Пример употребления: Нам нужно исправить все баги перед тем, как выпустить новую версию приложения. Аналог на русском — “ошибка”.

10. Бас Фактор (англ. “bus factor”, иногда также называется «truck factor») — это термин в IT, который используется для описания того, насколько зависим проект от конкретных сотрудников. Он определяет минимальное количество ключевых сотрудников в команде, которые должны быть на рабочем месте, чтобы проект мог продолжаться без значительных проблем. Пример употребления: «Компания осознавала, что её бас фактор слишком низок, поэтому начала активно нанимать и обучать новых разработчиков». Аналог на русском — “фактор производительности”.

11. Бдшка (сокращение от «база данных») — термин используется для описания базы данных или её компонентов. Пример использования: «Мы обнаружили проблему с индексами в нашей бдшке, которая замедляет выполнение запросов».

12. Билд (англ. “build”) — это сборка проекта из исходного кода, которая создаёт исполняемый файл или библиотеку. Пример употребления: «Мы успешно собрали билд проекта и готовы выкатить его на сервер.» Аналог на русском — “сборка”, “версия”.

13. Блочить (англ. “to block”) — ограничивать доступ к ресурсу или функциональности. Пример употребления: «Если пользователь вводит неверные данные, я блочу его аккаунт на некоторое время.» Также “блочить” означает заблокировать что-то или кого-то. Например: «Я заблочил эту задачу, чтобы никто другой не начал её делать». Аналог на русском — “блокировать”, “ограничивать”.

14. Брейншторм (англ. “brainstorm”) — процесс сбора и обсуждения идей для решения определённой проблемы или создания нового продукта. Пример употребления: “Мы провели брейншторм на тему новых функций для нашего приложения.” Аналог на русском — “генерация идей”.

15. Бэклог (англ. “backlog”) — это список задач или проектов, которые нужно выполнить в будущем. Пример употребления: «Мы добавили новую задачу в бэклог и займёмся ей после того, как закончим текущие проекты». Аналог на русском — “список задач”.

16. Вайпнуть (англ. “wipe”) — это удалить все данные или настройки из программы или устройства. Пример употребления: «Если что-то идёт не так, можешь попробовать вайпнуть телефон и начать сначала». Аналог на русском — “удалить”, “очистить”.

17. Валидация (англ. «validation») — процесс проверки правильности и соответствия данных определённым требованиям. Пример употребления: «Нужно добавить валидацию поля ввода, чтобы пользователь не мог указывать некорректные данные». Аналог на русском — “проверка”.

18. Веб-морда — это сокращённое выражение от «веб-интерфейс» или «веб-страница», то есть часть веб-приложения, которая видна и доступна для пользователя через браузер. Пример употребления: «Нам нужно сделать новую веб-морду для нашего онлайн-магазина». Аналог на русском — “внешний вид”.

19. Ворнинг (англ. “warning”) — это сообщение об ошибке или предупреждение о возможной проблеме в приложении. Пример употребления: «Пользователи начали жаловаться на этот ворнинг, который появляется при запуске приложения». Аналог на русском — “предупреждение”.

20. Выкатить билд (англ. build) — это загрузка собранного проекта на сервер. Пример употребления: «Команда готова выкатить билд на тестовый сервер для дальнейшего тестирования». Аналог на русском — “выпустить версию”.

21. Гайдлайн (англ. “guideline”) — руководство или инструкция, которая описывает, как выполнять определённую задачу или проект. Пример употребления: “Перед началом работы над проектом мы ознакомились с гайдлайнами компании”. Аналог на русском — “руководство”, ”инструкция”.

22. Галера — это сложный, запутанный код, который сложно понимать и поддерживать. Пример употребления: «Этот проект — настоящая галера, полная нечитаемого и запутанного кода.» Также используется в значении большой команды, которая работает над каким-то крупным проектом в компании. Это выражение может относиться как к команде разработчиков, так и к команде проектного менеджмента, тестирования, дизайна и т.д. Пример употребления: «На проекте у нас работает большая галера, включая 15 разработчиков, 3 дизайнера и 2 тестировщика».

23. Говнокод — некачественный, плохо написанный код. Пример употребления: “Я не могу работать с этим проектом, тут только говнокод.”

24. Груминг (англ. “grooming”) — процесс поддержки и оптимизации кода. Пример употребления: “Мы проводим еженедельный груминг, чтобы поддерживать наш код в хорошем состоянии.” Аналог на русском — “оптимизация”.

25. Грязный хак (англ. “dirty hack”) — нестандартное действие разработчиков, которое не является оптимальным или правильным решением, но позволяет решить проблему в кратчайшие сроки. Пример употребления: “Я применил грязный хак, чтобы исправить ошибку, пока не найду более правильное решение”. Аналог на русском — “некачественное решение”.

26. Дебаг, дебажить (англ. «debug») — процесс поиска и исправления ошибок в программном коде. Пример употребления: «Я провожу дебаг программы, чтобы исправить все ошибки перед тем, как выкатить релиз». Аналог на русском — “исправлять ошибки”.

27. Девопс (англ. “devops”) — это методология, объединяющая разработку (dev) и операции (ops) с целью улучшения совместной работы команды и оптимизации процессов разработки и эксплуатации ПО. Пример употребления: «Наша девопс команда обеспечивает автоматизацию инфраструктуры, быструю выкатку билдов и быстрое реагирование на проблемы в продакшн-среде.»

28. Дейли (англ. “daily meeting”) — ежедневное совещание команды разработки, на котором обсуждаются проделанная работа, планы на день и задачи. Пример употребления: На дейли мы обсудили текущие задачи и взаимодействие между разными отделами проекта. Аналог на русском — “ежедневный отчет”.

29. Демо, демка (англ. “demo”) — это показ приложения или функциональности заказчику или коллегам. Пример употребления: «Мы собираемся провести для заказчика демо новой функциональности на следующей неделе». Аналог на русском — “демонстрация продукта”.

30. Деплой (англ. “deploy”) — это процесс размещения кода или приложения на сервере или другой инфраструктуре, где он может быть использован. Пример употребления: “Сегодня мы будем делать деплой новой версии приложения на сервере”. Аналог на русском — “размещение”.

31. Деприкейтед (англ. «deprecated») — устаревший, устаревающий, не рекомендуемый к использованию. Пример употребления: «Этот метод был отмечен как деприкейтед, вместо него рекомендуется использовать другой метод». Аналог на русском — “устаревший”.

32. Дёргать ручку — внести изменения в код, чтобы исправить ошибку. Пример употребления: “Я должен был дёрнуть ручку, чтобы исправить эту ошибку в нашем приложении”.

33. Допка — дополнительная задача, которую разработчик должен выполнить помимо основной задачи. Пример употребления: «Я сейчас занят основной задачей, но как только её закончу, возьмусь за допку».

34. Дроп, дропнуть (англ. “drop”) — удаление, отмена чего-либо. Пример употребления: “Я случайно дропнул все изменения в ветке разработки”. Аналог на русском — “удалить”.

35. Закрыть протоколом — завершить процесс в соответствии с установленными правилами и процедурами. Пример употребления: “Нам нужно закрыть протоколом все изменения в коде перед выпуском новой версии приложения”.

36. Замокать для демо (англ. “mock”) — временно закрыть или ограничить доступ к функциональности, чтобы продемонстрировать приложение без риска сбоев. Пример употребления: «Я замокал эту функциональность для демо, чтобы избежать возможных ошибок.» Аналог на русском — “закрыть”.

37. Зафигачить костылей — это быстрое и не самое оптимальное решение задачи, без учёта долгосрочных последствий. Пример употребления: «Я зафигачил костылей, чтобы хоть так поработало, пока я занимаюсь другими задачами».

38. Кейс (англ. “case”) — сценарий использования. Пример употребления: “Мы должны протестировать нашу систему на нескольких кейсах, чтобы убедиться в её работоспособности”. Также употребляется в значении “реализованный проект”. Пример употребления: “Вы можете ознакомиться с нашими кейсами на сайте”. Аналог на русском — “случай”, “дело”.

39. Клауд (англ. “cloud”) — облачное хранилище данных и программного обеспечения. Пример употребления: «Я сохранил все свои фотографии в клауде, так удобнее, чем хранить на компьютере». Аналог на русском — “облако”, “облачное хранилище”.

40. Коммит (англ. “commit”) — действие по сохранению изменений в репозитории, чтобы они стали частью проекта. Пример употребления: “Я закоммитил изменения в коде, чтобы они стали доступны другим разработчикам.” Аналог на русском — “сохранить изменения”.

41. Компиляция (англ. “сompilation”) — процесс преобразования исходного кода программы в машинный код. Пример употребления: “Я запустил компиляцию исходного кода на C++ в машинный код”. Аналог на русском — “преобразование”.

42. Контроллер (англ. “controller”) — часть приложения, которая обрабатывает запросы от пользователей и возвращает им результаты. Пример употребления: «Я создал новый контроллер для работы с заказами пользователей». Аналог на русском — “управляющий компонент”.

43. Креды (англ. “credentials”) — учётная запись пользователя, логин и пароль. Пример употребления: “Я забыл свои креды от этой учётной записи, нужно сбросить пароль.” Аналог на русском — “учётные данные”.

44. Кэш (англ. “cash”) — временное хранилище данных для быстрого доступа к ним. Пример употребления: «Мы должны очистить кэш, чтобы освободить место на сервере». Аналог на русском — “временное хранилище”.

Л-Р

45. Легаси код (англ. “legacy code”) — устаревший код, который не соответствует современным стандартам. Пример употребления: “Мы должны переписать этот легаси код, чтобы наше приложение стало более эффективным”. Аналог на русском — “устаревший код”.

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

47. Лежит/Лежать — фраза, означающая, что сервер или платформа не работает. Пример употребления: “Что-то лежит на сервере, мы не можем получить доступ к нашему проекту”.

48. Либа (англ. “library”) — библиотека, набор программных модулей, функций или классов, которые используются для упрощения разработки программного обеспечения. Пример употребления: «Я использую либу NumPy для работы с матрицами в моём проекте». Аналог на русском — “библиотека”.

49. Логи (англ. “log”) — это записи о том, что происходит в приложении или на сайте, которые помогают выявить ошибки и проблемы. Пример употребления: “Если у тебя возникли проблемы с приложением, присылай логи разработчикам, чтобы они могли их проанализировать.” Аналог на русском — “записи”.

50. Лочить (англ. “lock”) — блокировать доступ к определённым ресурсам или функциям для предотвращения их неправильного использования. Пример употребления: «Разработчик залочил доступ к определённой функции, чтобы предотвратить ошибки в работе приложения». Аналог на русском — “блокировать”.

51. Мержить (англ. “merge”) — процесс объединения изменений из разных веток разработки в одну основную ветку. Пример употребления: “Я собираюсь мержить свои изменения в основную ветку разработки”. Аналог на русском — “объединять”.

52. Митап (англ. “meet up”) — это встреча разработчиков, на которой они обсуждают различные технические вопросы и делятся опытом. Пример употребления: «На этом митапе мы обсудим новые тенденции в разработке веб-приложений». Аналог на русском — “встреча”.

53. Мокать (англ. “mock”) — означает создание имитации компонентов или функций, чтобы проверить работоспособность других частей программы. Это делается, когда необходимо протестировать код, но реальные компоненты ещё не готовы или недоступны. Пример употребления: “Если программа взаимодействует с веб-сервисом, но этот сервис ещё не разработан или недоступен, то можно замокать его.” Аналог на русском — “имитировать”.

54. Монолит — программная архитектура, где весь код приложения находится в одном большом модуле или монолите. Такой подход может приводить к трудностям в поддержке, масштабировании и расширении приложения. Пример употребления: «Наша старая система была построена на монолите, и мы тратили много времени на обновления и деплойменты.”

55. Накатить — означает установить, развернуть или обновить приложение или программное обеспечение. Пример употребления: «Мы должны накатить последнюю версию операционной системы на сервер».

56. Окружение — описание конфигурации компьютерной системы, в которой запускается программное обеспечение. Окружение может включать в себя операционную систему, библиотеки, настройки сети и другие компоненты, которые необходимы для работы приложения. Пример употребления: «У меня есть проблема с запуском проекта на продакшн-окружении. Я не могу понять, почему он не работает так, как на локальной машине».

57. Онбординг (англ. “onboarding”) — это процесс введения новых сотрудников в компанию и ознакомления их с её культурой и процессами. Пример употребления: «Мы улучшили процесс онбординга, чтобы новые сотрудники быстрее вливались в коллектив». Аналог на русском — “адаптация”, “вводный курс”.

58. Опенсорсная библиотека (англ. “open source library”) — библиотека с открытым исходным кодом, доступная для использования другими разработчиками. Пример употребления: “Мы используем опенсорсную библиотеку для ускорения разработки нашего приложения”. Аналог на русском — “библиотека с открытым исходным кодом”.

59. Отрепортить (англ. “report”) — действие по отправке отчёта. Пример употребления: “Я отрепортил результаты тестирования нашего продукта”. Аналог на русском — “сообщить”.

60. Парсинг (от англ. parsing) — это процесс анализа и разбора данных, текста или программного кода с целью извлечения нужной информации. Пример употребления: «Наша компания разрабатывает продукт, который осуществляет автоматический парсинг данных с веб-сайтов конкурентов для анализа цен и ассортимента товаров». Аналог на русском — “анализ”.

61. Парсить (англ. “parse”) — преобразовывать данные из одного формата в другой, обычно в компьютерном контексте. Пример употребления: “Мы парсим данные из формата CSV в формат JSON для обработки в нашей системе”. Аналог на русском — “преобразовывать”.

62. Пермишен (англ. “permission”) — означает разрешение, которое пользователь должен дать для использования определённой функции или доступа к определённым данным. Пример употребления: «Пользователь должен дать пермишен на доступ к его контактам». Аналог на русском — “разрешение”.

63. Пинг (англ. “ping”) — измерение времени, за которое данные отправляются и возвращаются от устройства или сервера в сети. Пример употребления: “Я попробую пингануть наш сервер, чтобы узнать, как долго он отвечает.” Аналог на русском — “проверка связи”.

64. Пнуть — отправить запрос на сервер или сетевое устройство с целью проверить его доступность. Пример употребления: «Если сервер не отвечает, попробуй пнуть его и посмотреть, есть ли ответ». Также используется в значении “Напомнить”, например: “Пни меня через час, я гляну эту задачу”.

65. Предиктить (англ. “predict”) — прогнозировать событие или поведение на основе имеющихся данных или опыта. Пример употребления: «Наша команда использовала модель машинного обучения, чтобы предиктить будущие продажи». Аналог на русском — “прогнозировать”.

66. Прилка — используется в значении «приложение на мобильном устройстве». Пример употребления: «Нам нужно выпустить новую версию нашей прилки до конца месяца, чтобы добавить новые функции и улучшить производительность».

67. Прод (англ. “production”) — сокращённое слово от «продакшн», означающее окружение реальной работы, в отличие от окружения разработки или тестирования. Пример употребления: «Новый билд прошёл все тесты и готов к выкатке в прод». Аналог на русском — “рабочая среда”, “рабочее окружение”.

68. Профилировать — измерять производительность и выявлять узкие места в коде программы. Профилирование может помочь оптимизировать работу программы и улучшить её производительность. Пример употребления: “Я профилировал код и обнаружил, что наибольшее количество времени занимает выполнение функции обработки изображений”.

69. Пулл-реквест (англ. “pull request”) — это запрос на слияние внесённых изменений в код проекта с основной веткой разработки. Пример употребления: «Я отправил пулл-реквест с изменениями, которые внёс на прошлой неделе». Аналог на русском — “запрос на включение изменений”.

70. Пуш (англ. “push”) — отправка изменений в удалённый репозиторий. Пример употребления: «Я внёс несколько изменений в код и готов сделать пуш.» Аналог на русском — “отправить”, “загрузить изменения”.

71. Разраб (разработчик) — человек, который занимается разработкой программного обеспечения. Пример употребления: «Я работаю разрабом в крупной IT компании».

72. Раскатить — используется в значении «развернуть» или «применить» изменения или обновления в системе. Пример употребления: «Мы планируем раскатить новую версию приложения на следующей неделе».

73. Раскотить — отменить изменения, сделанные в системе контроля версий, таких как Git. Пример употребления: «Я случайно удалил важный файл, но успел раскотить коммит и всё вернулось к прежнему состоянию».

74. Распилить монолит — это разделение большого приложения на более мелкие, управляемые сервисы. Пример употребления: «Мы решили распилить монолит, чтобы облегчить его поддержку и развитие».

75. Расшарить (англ. “share”) — предоставить доступ к файлам, папкам или ресурсам другим пользователям или устройствам через сеть. Пример употребления: «Мне нужно расшарить эту папку, чтобы мои коллеги могли просмотреть содержимое и внести свои правки в проект». Аналог на русском — “поделиться”.

76. Ревью (англ. “code review”) — процесс проверки и анализа кода другими разработчиками. Пример употребления: “Я завершил работу над фичей и отправил на ревью своему коллеге”. Аналог на русском — “проверка”.

77. Ревьюить — проверять и анализировать код других разработчиков. Пример употребления: “Меня попросили ревьюить код коллеги и высказать свои замечания и предложения”. Аналог на русском — “проверять”.

78. Резолвить (англ. “resolve”) — означает разрешать, решать проблему или конфликт. Пример употребления: «Нам нужно резолвить эту проблему с сервером, чтобы наш сайт работал нормально». Аналог на русском — “решать проблему”.

79. Релоад (англ. “reload”) — это перезагрузка страницы или программы. Пример употребления: «Комп неожиданно ушёл в релоад». Аналог на русском — “перезагрузка”.

80. Репорт (англ. “report”) — документ, который содержит информацию о каком-то событии, действии, проблеме или результате исследования. Пример употребления: “Я подготовил репорт о тестировании нового продукта.” Аналог на русском — “отчёт”.

81. Ретро (англ. “retrospective”) — это совместное обсуждение прошлых достижений и неудач в проекте с целью извлечения уроков и оптимизации процессов. Пример употребления: «Мы планируем провести ретро после окончания этой фазы проекта.» Аналог на русском — “анализ проделанной работы”.

82. Рефакторинг (англ. “refactoring”) — процесс улучшения и оптимизации существующего кода. Пример употребления: “Я провел рефакторинг этой функции и теперь она работает быстрее.” Аналог на русском — “улучшение кода”.

83. Рисёрч (англ. “research”) — исследование и анализ какой-то темы или проблемы. Пример употребления: “Чтобы сделать правильный выбор, нужно провести рисёрч и проанализировать все существующие варианты.” Аналог на русском — “исследование”.

С-Я

84. Саппорт (англ. “support”) — помощь пользователям, обеспечение работы и технической поддержки продукта или сервиса. Пример употребления: “Я работаю в отделе саппорта и помогаю пользователям решать их задачи с помощью нашего продукта”. Аналог на русском — “поддержка”.

85. Синкануться, засинкать (англ. “synchronize”) — синхронизироваться с другим устройством или сервером для обмена данными. Пример употребления: “Давайте синканёмся с сервером, чтобы получить последние обновления”, «Я засинкал свой календарь с телефоном, чтобы ничего не пропустить.» Аналог на русском — “синхронизироваться”.

86. Скинуть спеку (англ. “specification”) — отправить техническое задание или спецификацию кому-либо для рассмотрения. Пример употребления: “Я скинул спеку моему коллеге, чтобы он мог ознакомиться и дать обратную связь.” Аналог на русском — “отправить ТЗ”.

87. Скоуп тасок (англ. “scope”) — означает объём работ, который нужно выполнить. Пример употребления: «Мы должны определить скоуп тасок, чтобы понимать, сколько времени займёт наш проект». Аналог на русском — “объём работы”, “список задач”.

88. Сов (англ. “scope of work”) — объём работы, который должен быть выполнен в рамках проекта. Пример употребления: “Сейчас мы работаем над определением сов — необходимо чётко определить, что именно мы будем разрабатывать и какие функциональные требования должны быть учтены». Аналог на русском — “объём работ на проекте”.

89. Софт (англ. “software”) — программное обеспечение компьютера. Пример употребления: «У меня сегодня проблемы с софтом, не могу запустить нужную программу». Аналог на русском — “программное обеспечение (ПО)”.

90. Спека (англ. “specification”) — в айтишном сленге обычно используется в значении «нагрузочное тестирование» — это процесс проверки производительности системы или приложения при максимальной или экстремальной нагрузке. Пример употребления: «Мы проводим спеку нашего нового онлайн-магазина, чтобы убедиться, что он выдержит максимальную нагрузку во время распродажи». Аналог на русском — “спецификация”, “техническое задание«.

91. Таска (англ. “task”) — задача, которую необходимо выполнить в рамках проекта или работы. Пример употребления: “Моя следующая таска — написать документацию для нашего проекта”. Аналог на русском — “задача”.

92. Тег (англ. «tag») — метка, которую можно присвоить объекту, например, задаче, багу. Пример употребления: «Добавьте тег ‘новый функционал’ к задаче». Аналог на русском — “метка”.

93. Тегнуть (англ. «tag») — присвоить тег (метку) объекту для более удобного поиска или классификации. Пример употребления: «Тегните этот баг #1234 меткой ‘важный'». Также может использоваться в значении упоминания кого-либо в чате. Например, “Тегни меня, когда я понадоблюсь”. Аналог на русском — “отметить”.

94. Тикет (англ. «ticket») — запрос в службу поддержки или жалобу на проблему, которую необходимо решить. Это может быть как технический вопрос, так и проблема с заказом или оплатой. Пример употребления: «Я отправил тикет в службу поддержки, чтобы исправить проблему с моим аккаунтом». Аналог на русском — “заявка”, “запрос”.

95. Топик (англ. “topic”) — используется для обозначения темы, которая обсуждается на форуме, в чате или в другом онлайн-сообществе. Также этот термин может использоваться для обозначения конкретного сообщения или поста в рамках обсуждаемой темы. Пример употребления: “Я создал новый топик на форуме и спросил, как работать с этой с библиотекой. Жду, когда кто-то ответит на мой вопрос”. Аналог на русском — “тема”.

96. Трек (англ. “track”) — это система отслеживания ошибок, задач и прогресса в проекте. Пример употребления: «Я добавил новую задачу в трек проекта». Аналог на русском — “система отслеживания”.

97. Трекнуть (англ. “track”) — добавить задачу или ошибку в систему отслеживания. Пример употребления: «Я только что трекнул новую ошибку в систему.» Аналог на русском — “отследить”.

98. Убить прилку — завершить работу приложения или процесса. Пример употребления: “Я должен убить эту прилку, потому что она не отвечает”.

99. Уронить что-либо — описание сбоя или непреднамеренной ошибки в коде, базе данных или других системах. Пример употребления: «Оператор случайно удалил таблицу из базы данных и уронил всю систему».

100. Факап (англ. “fuck up”) — означает ошибку или неудачу. Пример употребления: «Я сделал факап при обновлении базы данных, и теперь нам нужно восстанавливать данные». Аналог на русском — “ошибка”, “провал”.

101. Фича (англ. “feature”) — функция или возможность, которую предоставляет продукт или сервис. Пример употребления: “Мы добавили новую фичу в наше приложение, которая позволяет пользователям отправлять сообщения друг другу.” Аналог на русском — “особенность”, “функция”.

102. Фичатогл (англ. “feature toggle”) — техника разработки, которая позволяет изменять функционал приложения без перекомпиляции. Пример употребления: “Необходимо добавить фичатогл, чтобы можно было включать и выключать функционал экспериментальной функции для тестирования”.

103. Фичафлаг (англ. “feature flag”) — техника разработки, которая позволяет изменять функционал приложения для определённых пользователей или групп пользователей. Пример употребления: “Мы добавили фичафлаг для тестирования нового функционала для слабовидящих”.

104. Хак (англ. “hack”) — быстрое и неортодоксальное решение проблемы или задачи. Пример употребления: “Я использовал хак для устранения ошибки в нашем приложении”. Аналог на русском — “взлом”, “быстрое решение”.

105. Хакинтош (англ. “hackintosh”) — это компьютер, который был создан из неоригинальных компонентов, но работает под управлением операционной системы Mac OS X, предназначенной для компьютеров от Apple. Такой компьютер можно собрать самостоятельно или купить у специализированных продавцов. Пример употребления: «Я собрал Хакинтош на базе Intel-платформы, и он работает очень хорошо с новой версией Mac OS X».

106. Хоткей (англ. “hotkey”) — это сочетание клавиш на клавиатуре, которое позволяет быстро выполнять определенные действия. Пример употребления: «Я часто использую хоткей Ctrl+C, чтобы скопировать текст». Аналог на русском — “горячие клавиши”, “сочетание клавиш”.

107. Хотфикс (англ. “hotfix”) — это небольшое изменение в программном коде, которое вносится для решения конкретной проблемы без перекомпиляции всего приложения. Пример употребления: «Мы внедрили хотфикс для устранения ошибки в работе приложения”. Аналог на русском — “небольшое изменение”.

108. Юзабилити (англ. “usability”) — означает удобство использования продукта для пользователя. Пример употребления: «Нам нужно улучшить юзабилити нашего сайта, чтобы пользователи могли быстро находить нужную информацию». Аналог на русском — “удобство использования”.

Итак, сегодня мы раскатали этот топик про сленг айтишников, научились митапить, мержить, профилировать и даже поняли, что такое галера и сов. Давайте расшифруем?

Как обычно пишут программы

Традиционный цикл разработки программ выглядит так:

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

Минусы поэтапной разработки

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

Проблема в том, что у каждого из этих отделов своё рабочее окружение: они сами следят за своими библиотеками, фреймворками и операционной системой. Из-за этого то, что работает у одних, может не работать у других.

В итоге все тратят время на синхронизацию требований к коду, компонентам, фреймворкам и библиотекам. Работа стоит, код не пишется.

DevOps-подход к разработке

Изначально термином DevOps описывали только сам подход к разработке софта, но потом этим термином стали называть новую профессию. DevOps-подход в общих чертах можно описать так:

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

Кто такие девопсы и что они делают

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

Вот что может делать девопс-инженер:

👉 Главная задача девопса — сделать так, чтобы автоматизации было как можно больше и чтобы она действительно ускоряла разработку.

Что нужно уметь

Чтобы стать девопсом, нужно освоить много разного:

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

Деньги

По данным Хабр Карьеры, в первом полугодии 2021 года средняя зарплата девопс-инженера — 171 тысяча в месяц. Джуниоры получают в среднем 82 тысячи, а сеньоры — 230 тысяч.

Что дальше

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