Google cloud - Шпаргалка (Mobile)

Базовые понятия GCP

AI/ML с точки зрения бэкенда. Model response Thinking Thoughts (experimental) Auto

Expand to view model thoughts chevron_right Model response Thinking Thoughts (experimental) Auto

Expand to view model thoughts chevron_right

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

Токен (Token)

Объяснение: Токен — это минимальная единица текста, с которой оперирует модель.[1] Модели не работают со словами или буквами напрямую, а разбивают текст на эти базовые "кирпичики". Токеном может быть целое слово, часть слова (например, приставка или окончание), знак препинания или даже пробел.[2][3]

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

Пример: Фраза «Hello, world!» может быть разбита на следующие токены: ["Hello", ",", " ", "world", "!"]. Английское слово «running» может быть разделено на два токена: ["runn", "ing"].[3] 2. Контекстное окно (Context Window)

Объяснение: Контекстное окно — это максимальный объем информации (измеряемый в токенах), который модель может "видеть" и учитывать в один момент времени при генерации ответа.[4] Это своего рода кратковременная память модели. Все, что не помещается в это окно, модель "забывает".[5]

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

Пример: Если у модели контекстное окно 8000 токенов, то она может одновременно учитывать ваш запрос и предыдущий диалог, суммарный объем которых не превышает этот лимит. Если вы отправите ей документ на 10000 токенов, она "увидит" только первые 8000 и проигнорирует конец.[4] 3. Температура (Temperature)

Объяснение: Температура — это параметр, который контролирует степень случайности или "креативности" ответа модели.[6] Он влияет на то, как модель выбирает следующий токен.

Низкая температура (ближе к 0): Модель становится более предсказуемой и детерминированной. Она почти всегда будет выбирать самый вероятный следующий токен.[7]

Высокая температура (ближе к 1 и выше): Модель становится более "смелой" и креативной, увеличивая вероятность выбора менее очевидных токенов.[7]

Аналогия: Температура — это "регулятор творческого риска". Низкое значение — это строгий и консервативный редактор, который придерживается фактов. Высокое значение — это поэт-экспериментатор, который любит неожиданные метафоры.

Пример:

Запрос: "Напиши слоган для кофейни".

Температура 0.1: "Лучший кофе в городе." (очевидно и предсказуемо).

Температура 0.9: "Кофе, который заставит ваши атомы танцевать." (креативно и неожиданно).

Top-K

Объяснение: Параметр Top-K ограничивает выбор следующего токена только K самыми вероятными вариантами. Модель сначала отбирает K токенов с наивысшей вероятностью, а затем выбирает следующий токен только из этого сокращенного списка.[8]

Аналогия: Представьте, что модель выбирает десерт из меню. Top-K=3 означает, что она будет рассматривать только три самых популярных десерта в меню, полностью игнорируя все остальные.

Пример: Если после слова "Я люблю..." модель предсказывает: "кофе" (вероятность 40%), "чай" (30%), "гулять" (15%), "спать" (10%), "работу" (5%).

При Top-K=2, модель будет выбирать только между "кофе" и "чай".

Top-P (Nucleus Sampling)

Объяснение: Параметр Top-P (или Nucleus Sampling) — это другой способ ограничить выбор. Вместо фиксированного числа вариантов (как в Top-K), он отбирает токены, суммарная вероятность которых превышает порог P.[9] Это позволяет создавать динамический список кандидатов: если модель очень уверена в одном-двух вариантах, список будет коротким, а если уверенность распределена между многими вариантами — длиннее.

Аналогия: Возвращаясь к меню десертов. Top-P=0.8 (или 80%) означает, что модель будет выбирать из самых популярных десертов, пока их суммарная популярность не достигнет 80%. Если "Тирамису" имеет популярность 70%, а "Чизкейк" — 15%, то в выборку попадут оба.

Пример: В той же ситуации, что и выше, при Top-P=0.8:

Модель сложит вероятности: "кофе" (40%) + "чай" (30%) + "гулять" (15%) = 85%.

Поскольку 85% > 80%, она будет выбирать из этих трех вариантов: "кофе", "чай" или "гулять".

Эмбеддинг (Embedding)

Объяснение: Эмбеддинг — это преобразование текста (или другого объекта, например, изображения) в числовой вектор (массив чисел).[10] Этот вектор отражает семантическое значение исходного текста.[11] Слова с похожим смыслом будут иметь близкие по значению векторы.[10]

Аналогия: Представьте, что каждое слово — это точка на большой карте. Эмбеддинг — это GPS-координаты этой точки. Слова "король" и "королева" будут находиться на карте очень близко друг к другу. Слово "банан" будет где-то рядом с "фруктом", но очень далеко от "автомобиля".

Пример: Слово "кошка" может быть представлено как вектор [0.12, -0.45, 0.89, ...], а слово "кот" будет иметь очень похожий вектор [0.14, -0.42, 0.91, ...]. Это позволяет машине "понимать" смысловую близость. 7. Векторная база данных (Vector Database)

Объяснение: Векторная база данных — это специализированная база данных, предназначенная для хранения и эффективного поиска эмбеддингов (векторов).[12] Вместо поиска по точному совпадению текста, она ищет "ближайших соседей" — векторы, которые наиболее похожи на вектор запроса.[13]

Аналогия: Это как библиотека, где книги расставлены не по алфавиту, а по смыслу. Если вы ищете книгу о "королях и замках", библиотекарь (векторная база) мгновенно покажет вам полку, где стоят книги о "средневековье", "монархии" и "рыцарях".

Пример: Вы загружаете в векторную базу данных сотни документов о продуктах вашей компании. Когда пользователь спрашивает "какой смартфон лучше для фото?", система превращает этот вопрос в вектор и ищет в базе документы, векторы которых наиболее близки к вектору вопроса. 8. Галлюцинации (Hallucinations)

Объяснение: Галлюцинация — это явление, когда LLM генерирует ответ, который выглядит правдоподобно, грамматически верен, но является фактически неточным, выдуманным или не основанным на предоставленном контексте.[14][15] Модель "придумывает" факты, потому что ее основная задача — предсказать следующее наиболее вероятное слово, а не говорить правду.

Аналогия: Это как слишком уверенный в себе студент, который, не зная ответа на экзамене, не молчит, а начинает уверенно и красиво сочинять, смешивая обрывки знаний с вымыслом.

Пример: Запрос: "Кто был первым человеком, проплывшим через Атлантический океан на резиновой лодке?" Галлюцинация: "Первым человеком, совершившим это путешествие, был знаменитый исследователь сэр Арчибальд Фипс в 1882 году на своей лодке 'Непотопляемый II'." (Такого человека и события никогда не существовало). 9. Инференс (Inference)

Объяснение: Инференс — это процесс использования уже обученной модели для генерации ответов или предсказаний на основе новых, ранее не виденных данных.[16] Это практическое применение модели после завершения ее долгого и дорогостоящего обучения.[17]

Аналогия: Если обучение модели — это годы учебы в университете, то инференс — это ее работа в реальном мире, где она применяет полученные знания для решения ежедневных задач.[16]

Пример: Каждый раз, когда вы отправляете запрос в ChatGPT и получаете ответ, вы запускаете процесс инференса. Модель не обучается на вашем запросе, а просто использует свои существующие "знания" для генерации результата. Sources help

habr.com
vc.ru
vc.ru
systems-analysis.ru
colobridge.net
yandex.cloud
systems-analysis.ru
medium.com
vellum.ai
habr.com
deepmachinelearning.ru
habr.com
amazon.com
astera.com
unite.ai
dns-shop.ru
mediapark.uz

Google Search Suggestions Display of Search Suggestions is required when using Grounding with Google Search. Learn more Google logo 29.6s Use Arrow Up and Arrow Down to select a turn, Enter to jump to it, and Escape to return to the chat.

Глоссаррий

1. Токен (Token)

Объяснение: Токен — это минимальная единица текста, с которой оперирует модель. Модели не работают со словами или буквами напрямую, а разбивают текст на эти базовые "кирпичики". Токеном может быть целое слово, часть слова (например, приставка или окончание), знак препинания или даже пробел.

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

Пример: Фраза «Hello, world!» может быть разбита на следующие токены: ["Hello", ",", " ", "world", "!"]. Английское слово «running» может быть разделено на два токена: ["runn", "ing"].

2. Контекстное окно (Context Window)

Объяснение: Контекстное окно — это максимальный объем информации (измеряемый в токенах), который модель может "видеть" и учитывать в один момент времени при генерации ответа. Это своего рода кратковременная память модели. Все, что не помещается в это окно, модель "забывает".

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

Пример: Если у модели контекстное окно 8000 токенов, то она может одновременно учитывать ваш запрос и предыдущий диалог, суммарный объем которых не превышает этот лимит. Если вы отправите ей документ на 10000 токенов, она "увидит" только первые 8000 и проигнорирует конец.

3. Температура (Temperature)

Объяснение: Температура — это параметр, который контролирует степень случайности или "креативности" ответа модели. Он влияет на то, как модель выбирает следующий токен.

Низкая температура (ближе к 0): Модель становится более предсказуемой и детерминированной. Она почти всегда будет выбирать самый вероятный следующий токен.
Высокая температура (ближе к 1 и выше): Модель становится более "смелой" и креативной, увеличивая вероятность выбора менее очевидных токенов.

Аналогия: Температура — это "регулятор творческого риска". Низкое значение — это строгий и консервативный редактор, который придерживается фактов. Высокое значение — это поэт-экспериментатор, который любит неожиданные метафоры.

Пример:

Запрос: "Напиши слоган для кофейни".
Температура 0.1: "Лучший кофе в городе." (очевидно и предсказуемо).
Температура 0.9: "Кофе, который заставит ваши атомы танцевать." (креативно и неожиданно).

4. Top-K

Объяснение: Параметр Top-K ограничивает выбор следующего токена только K самыми вероятными вариантами. Модель сначала отбирает K токенов с наивысшей вероятностью, а затем выбирает следующий токен только из этого сокращенного списка.

Аналогия: Представьте, что модель выбирает десерт из меню. Top-K=3 означает, что она будет рассматривать только три самых популярных десерта в меню, полностью игнорируя все остальные.

Пример: Если после слова "Я люблю..." модель предсказывает: "кофе" (вероятность 40%), "чай" (30%), "гулять" (15%), "спать" (10%), "работу" (5%).

При Top-K=2, модель будет выбирать только между "кофе" и "чай".

5. Top-P (Nucleus Sampling)

Объяснение: Параметр Top-P (или Nucleus Sampling) — это другой способ ограничить выбор. Вместо фиксированного числа вариантов (как в Top-K), он отбирает токены, суммарная вероятность которых превышает порог P. Это позволяет создавать динамический список кандидатов: если модель очень уверена в одном-двух вариантах, список будет коротким, а если уверенность распределена между многими вариантами — длиннее.

Аналогия: Возвращаясь к меню десертов. Top-P=0.8 (или 80%) означает, что модель будет выбирать из самых популярных десертов, пока их суммарная популярность не достигнет 80%. Если "Тирамису" имеет популярность 70%, а "Чизкейк" — 15%, то в выборку попадут оба.

Пример: В той же ситуации, что и выше, при Top-P=0.8:

Модель сложит вероятности: "кофе" (40%) + "чай" (30%) + "гулять" (15%) = 85%.
Поскольку 85% > 80%, она будет выбирать из этих трех вариантов: "кофе", "чай" или "гулять".

6. Эмбеддинг (Embedding)

Объяснение: Эмбеддинг — это преобразование текста (или другого объекта, например, изображения) в числовой вектор (массив чисел). Этот вектор отражает семантическое значение исходного текста. Слова с похожим смыслом будут иметь близкие по значению векторы.

Аналогия: Представьте, что каждое слово — это точка на большой карте. Эмбеддинг — это GPS-координаты этой точки. Слова "король" и "королева" будут находиться на карте очень близко друг к другу. Слово "банан" будет где-то рядом с "фруктом", но очень далеко от "автомобиля".

Пример: Слово "кошка" может быть представлено как вектор [0.12, -0.45, 0.89, ...], а слово "кот" будет иметь очень похожий вектор [0.14, -0.42, 0.91, ...]. Это позволяет машине "понимать" смысловую близость.

7. Векторная база данных (Vector Database)

Объяснение: Векторная база данных — это специализированная база данных, предназначенная для хранения и эффективного поиска эмбеддингов (векторов). Вместо поиска по точному совпадению текста, она ищет "ближайших соседей" — векторы, которые наиболее похожи на вектор запроса.

Аналогия: Это как библиотека, где книги расставлены не по алфавиту, а по смыслу. Если вы ищете книгу о "королях и замках", библиотекарь (векторная база) мгновенно покажет вам полку, где стоят книги о "средневековье", "монархии" и "рыцарях".

Пример: Вы загружаете в векторную базу данных сотни документов о продуктах вашей компании. Когда пользователь спрашивает "какой смартфон лучше для фото?", система превращает этот вопрос в вектор и ищет в базе документы, векторы которых наиболее близки к вектору вопроса.

8. Галлюцинации (Hallucinations)

Объяснение: Галлюцинация — это явление, когда LLM генерирует ответ, который выглядит правдоподобно, грамматически верен, но является фактически неточным, выдуманным или не основанным на предоставленном контексте. Модель "придумывает" факты, потому что ее основная задача — предсказать следующее наиболее вероятное слово, а не говорить правду.

Аналогия: Это как слишком уверенный в себе студент, который, не зная ответа на экзамене, не молчит, а начинает уверенно и красиво сочинять, смешивая обрывки знаний с вымыслом.

Пример: Запрос: "Кто был первым человеком, проплывшим через Атлантический океан на резиновой лодке?" Галлюцинация: "Первым человеком, совершившим это путешествие, был знаменитый исследователь сэр Арчибальд Фипс в 1882 году на своей лодке 'Непотопляемый II'." (Такого человека и события никогда не существовало).

9. Инференс (Inference)

Объяснение: Инференс — это процесс использования уже обученной модели для генерации ответов или предсказаний на основе новых, ранее не виденных данных. Это практическое применение модели после завершения ее долгого и дорогостоящего обучения.

Аналогия: Если обучение модели — это годы учебы в университете, то инференс — это ее работа в реальном мире, где она применяет полученные знания для решения ежедневных задач.

Пример: Каждый раз, когда вы отправляете запрос в ChatGPT и получаете ответ, вы запускаете процесс инференса. Модель не обучается на вашем запросе, а просто использует свои существующие "знания" для генерации результата.

030-learning

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

Часть 1: Pre-training (Предварительное обучение) — "Прочитать всю библиотеку мира"

Что это такое?

Предварительное обучение, или pre-training, — это самый первый, самый долгий и самый масштабный этап создания модели. Его цель — научить модель фундаментальным законам человеческого языка: грамматике, синтаксису, фактам о мире, логическим связям и стилю. Модель на этом этапе не учат отвечать на вопросы, а учат понимать сам язык.

Как это происходит на практике?

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

Пример: Модель видит фразу: "Солнце светит очень ____, поэтому надень очки".
Она пытается предсказать пропущенное слово. Сначала ее догадки случайны: "грустно", "синий", "ярко".
После каждой попытки ей показывают правильный ответ ("ярко") и она немного корректирует свои внутренние параметры (миллиарды связей между нейронами), чтобы в следующий раз быть чуть точнее.

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

После "очень" часто идет наречие.
"Солнце" и "очки" связаны по смыслу.
Она изучает факты (например, что столица Франции — Париж, потому что эти слова часто встречаются вместе в определенном контексте).
Она учится стилю, читая и стихи, и научные статьи, и посты из соцсетей.

На каких данных это делается?

На всем, что человечество написало и выложило в цифровом виде. Это колоссальный объем данных:

Весь интернет: Огромные срезы интернета, такие как набор данных Common Crawl, который содержит петабайты веб-страниц.
Книги: Миллионы оцифрованных книг со всего мира.
Википедия: Вся Википедия на множестве языков — концентрированный источник фактов.
Научные статьи, новостные архивы, программный код (GitHub) и многое другое.

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

Часть 2: Fine-tuning (Дообучение) — "Пройти курс по конкретной профессии"

Что это такое?

Дообучение, или fine-tuning, — это второй, более короткий и целенаправленный этап. Мы берем уже "эрудированную" модель и дополнительно обучаем ее на небольшом, но очень качественном наборе данных, чтобы она научилась выполнять конкретную задачу или вести себя определенным образом.

Как это происходит на практике?

Теперь модель учат на примерах в формате "вопрос-ответ" или "инструкция-результат".

Пример: Мы показываем модели тысячи примеров диалогов:
- Инструкция: "Переведи 'Hello, world!' на французский".
- Правильный ответ: "Bonjour, le monde!".
- Инструкция: "Напиши короткое стихотворение о луне".
- Правильный ответ: (красивое стихотворение о луне).
- Инструкция: "Объясни, что такое фотосинтез, простыми словами".
- Правильный ответ: (понятное объяснение).

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

Для чего это нужно?

Дообучение позволяет "специализировать" модель:

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

Итог аналогии

Pre-training (Предварительное обучение): Человек тратит 20 лет, чтобы прочитать абсолютно все книги в Британской библиотеке. Теперь он знает все факты, все стили, всю грамматику. Он невероятно эрудирован, но немного "не от мира сего" и не очень хорошо понимает, как общаться с людьми.
Fine-tuning (Дообучение): Этот же человек идет на шестимесячные курсы, чтобы стать юристом (или врачом, или программистом). Ему не нужно заново учить язык — он использует свои гигантские знания и учится применять их для решения конкретных юридических задач, составления исков и консультирования клиентов. Он становится специалистом.

Pre-train

Часть 1: Pre-training (Предварительное обучение) — "Прочитать всю библиотеку мира"

Что это такое?

Как это происходит на практике?

Пример: Модель видит фразу: "Солнце светит очень ____, поэтому надень очки".
Она пытается предсказать пропущенное слово. Сначала ее догадки случайны: "грустно", "синий", "ярко".
После каждой попытки ей показывают правильный ответ ("ярко") и она немного корректирует свои внутренние параметры (миллиарды связей между нейронами), чтобы в следующий раз быть чуть точнее.

После "очень" часто идет наречие.
"Солнце" и "очки" связаны по смыслу.
Она изучает факты (например, что столица Франции — Париж, потому что эти слова часто встречаются вместе в определенном контексте).
Она учится стилю, читая и стихи, и научные статьи, и посты из соцсетей.

На каких данных это делается?

На всем, что человечество написало и выложило в цифровом виде. Это колоссальный объем данных:

Весь интернет: Огромные срезы интернета, такие как набор данных Common Crawl, который содержит петабайты веб-страниц.
Книги: Миллионы оцифрованных книг со всего мира.
Википедия: Вся Википедия на множестве языков — концентрированный источник фактов.
Научные статьи, новостные архивы, программный код (GitHub) и многое другое.

Часть 2: Fine-tuning (Дообучение) — "Пройти курс по конкретной профессии"

Что это такое?

Как это происходит на практике?

Теперь модель учат на примерах в формате "вопрос-ответ" или "инструкция-результат".

Пример: Мы показываем модели тысячи примеров диалогов:
- Инструкция: "Переведи 'Hello, world!' на французский".
- Правильный ответ: "Bonjour, le monde!".
- Инструкция: "Напиши короткое стихотворение о луне".
- Правильный ответ: (красивое стихотворение о луне).
- Инструкция: "Объясни, что такое фотосинтез, простыми словами".
- Правильный ответ: (понятное объяснение).

Для чего это нужно?

Дообучение позволяет "специализировать" модель:

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

Итог аналогии

Pre-training (Предварительное обучение): Человек тратит 20 лет, чтобы прочитать абсолютно все книги в Британской библиотеке. Теперь он знает все факты, все стили, всю грамматику. Он невероятно эрудирован, но немного "не от мира сего" и не очень хорошо понимает, как общаться с людьми.
Fine-tuning (Дообучение): Этот же человек идет на шестимесячные курсы, чтобы стать юристом (или врачом, или программистом). Ему не нужно заново учить язык — он использует свои гигантские знания и учится применять их для решения конкретных юридических задач, составления исков и консультирования клиентов. Он становится специалистом.

Конечно! Вот подробное руководство по искусству составления запросов к AI — промпт-инжинирингу.

Руководство по промпт-инжинирингу: Как общаться с AI

Промпт-инжиниринг — это не программирование, а скорее искусство и наука правильно формулировать запросы (промпты) для получения от языковой модели (LLM) максимально точного, полезного и релевантного ответа. Качество вашего запроса напрямую определяет качество результата.

Представьте, что вы даете задание очень умному, но крайне буквальному стажеру с доступом ко всей информации мира. Ему нужно дать предельно четкие инструкции.

Ключевые принципы эффективных промптов

Четыре столпа хорошего промпта — это ясность, контекст, роль и формат.

1. Ясность (Clarity): Будьте конкретны и однозначны. Модель не умеет читать ваши мысли. Избегайте двусмысленности.

Плохо: Расскажи о Java. (Слишком широко. О чем именно? Об истории? Синтаксисе? Плюсах?)
Хорошо: Опиши 3 ключевых преимущества языка программирования Java для создания enterprise-приложений на бэкенде.

2. Контекст (Context): Предоставьте всю необходимую информацию. Чем больше релевантных деталей вы дадите, тем лучше ответ будет соответствовать вашим ожиданиям.

Плохо: Напиши код для подключения к базе данных. (Какой базе данных? Какой язык программирования? Какая библиотека?)
Хорошо: Напиши пример кода на Java с использованием Spring Data JPA для подключения к базе данных PostgreSQL. Укажи необходимые зависимости для Maven и пример конфигурации в application.properties.

3. Роль (Persona): Укажите, кем должна быть модель. Назначение роли помогает модели адаптировать свой стиль, тон и лексику. Это один из самых мощных приемов.

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

4. Формат ответа (Format): Укажите, как должен выглядеть результат. Если вам нужен ответ в определенной структуре, попросите об этом прямо. Это особенно важно для интеграции с другими системами.

Плохо: Перечисли плюсы и минусы Kubernetes.
Хорошо: Предоставь информацию о плюсах и минусах Kubernetes в виде Markdown-таблицы с двумя колонками: "Преимущества" и "Недостатки".

Техники промптинга с примерами

1. Zero-shot Prompting (Запрос без примеров)

Это самый базовый тип запроса, когда вы просите модель выполнить задачу, не предоставляя ей ни одного примера. Модель полагается только на свои внутренние знания.

Задача: Определить тональность отзыва о товаре.
Плохой промпт:

Проанализируй отзыв: "В принципе, телефон неплохой, но батарея держит очень мало."
Хороший промпт:

Определи основную тональность (sentiment) следующего отзыва. Ответь одним словом: "Позитивный", "Негативный" или "Нейтральный".

Отзыв: "В принципе, телефон неплохой, но батарея держит очень мало."

Почему лучше: Мы дали четкую инструкцию и ограничили варианты ответа, что делает результат предсказуемым.

2. One-shot Prompting (Запрос с одним примером)

Вы даете модели один пример того, что вы от нее хотите. Это помогает ей лучше понять формат и суть задачи.

Задача: Преобразовать описание продукта в короткий рекламный слоган.
Плохой промпт:

Придумай слоган для наших новых наушников с шумоподавлением и 30-часовой работой от батареи.
Хороший промпт:

Преврати описание продукта в короткий, энергичный слоган.

Пример: Описание: Наш кофе сделан из 100% арабики и обжарен вручную. Слоган: Заряди свой день энергией совершенства!

Теперь твой черед: Описание: Наши новые наушники с активным шумоподавлением работают до 30 часов без подзарядки. Слоган:

Почему лучше: Пример задает тон и стиль, направляя креативность модели в нужное русло.

3. Few-shot Prompting (Запрос с несколькими примерами)

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

Задача: Извлечь из текста структурированную информацию.
Плохой промпт:

Извлеки из текста название товара и его цену. "Сегодня мы представляем новый смартфон Alpha One за $999."
Хороший промпт:

Извлеки из текста название продукта и его цену в формате JSON.

Текст: "Кофемашина 'Bravista 500' доступна по специальной цене 350 евро." JSON: {"product": "Bravista 500", "price": 350}

Текст: "Предзаказ на игровую консоль 'GameSphere X' открыт. Стоимость составит $499." JSON: {"product": "GameSphere X", "price": 499}

Текст: "Сегодня мы представляем новый смартфон Alpha One за $999." JSON:

Почему лучше: Несколько примеров помогают модели понять, как справляться с разными формулировками и четко следовать требуемой JSON-структуре.

4. Chain of Thought (CoT) Prompting (Промптинг "цепочкой мыслей")

Это продвинутая техника для решения логических, математических или многоэтапных задач. Вы просите модель "рассуждать вслух" или "думать по шагам" перед тем, как дать финальный ответ. Это значительно повышает точность.

Задача: Решить логическую задачку.
Плохой промпт:

На парковке 30 машин, часть из них красные, часть — синие. Если количество синих машин в два раза больше красных, сколько красных машин на парковке?

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

На парковке 30 машин, часть из них красные, часть — синие. Если количество синих машин в два раза больше красных, сколько красных машин на парковке?

Давай рассуждать по шагам.

Ожидаемый ответ модели:
Конечно, давай разберем это по шагам.
1. Определим переменные. Пусть К — это количество красных машин, а С — количество синих машин.
2. Составим уравнения на основе условий.
  - Всего машин 30: К + С = 30.
  - Синих в два раза больше, чем красных: С = 2 * К.
3. Решим систему уравнений. Подставим второе уравнение в первое: К + (2 * К) = 30 3 * К = 30
4. Найдем К. К = 30 / 3 К = 10
Ответ: На парковке 10 красных машин.
Почему лучше: Магическая фраза "Давай рассуждать по шагам" заставляет модель декомпозировать задачу, что снижает вероятность ошибки и делает ее "мыслительный" процесс прозрачным.

060-gcp_storage_cheatsheet

Часть 1: Pre-training (Предварительное обучение) — "Прочитать всю библиотеку мира"

Что это такое?

Как это происходит на практике?

Пример: Модель видит фразу: "Солнце светит очень ____, поэтому надень очки".
Она пытается предсказать пропущенное слово. Сначала ее догадки случайны: "грустно", "синий", "ярко".
После каждой попытки ей показывают правильный ответ ("ярко") и она немного корректирует свои внутренние параметры (миллиарды связей между нейронами), чтобы в следующий раз быть чуть точнее.

После "очень" часто идет наречие.
"Солнце" и "очки" связаны по смыслу.
Она изучает факты (например, что столица Франции — Париж, потому что эти слова часто встречаются вместе в определенном контексте).
Она учится стилю, читая и стихи, и научные статьи, и посты из соцсетей.

На каких данных это делается?

На всем, что человечество написало и выложило в цифровом виде. Это колоссальный объем данных:

Весь интернет: Огромные срезы интернета, такие как набор данных Common Crawl, который содержит петабайты веб-страниц.
Книги: Миллионы оцифрованных книг со всего мира.
Википедия: Вся Википедия на множестве языков — концентрированный источник фактов.
Научные статьи, новостные архивы, программный код (GitHub) и многое другое.

Часть 2: Fine-tuning (Дообучение) — "Пройти курс по конкретной профессии"

Что это такое?

Как это происходит на практике?

Теперь модель учат на примерах в формате "вопрос-ответ" или "инструкция-результат".

Пример: Мы показываем модели тысячи примеров диалогов:
- Инструкция: "Переведи 'Hello, world!' на французский".
- Правильный ответ: "Bonjour, le monde!".
- Инструкция: "Напиши короткое стихотворение о луне".
- Правильный ответ: (красивое стихотворение о луне).
- Инструкция: "Объясни, что такое фотосинтез, простыми словами".
- Правильный ответ: (понятное объяснение).

Для чего это нужно?

Дообучение позволяет "специализировать" модель:

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

Итог аналогии

Pre-training (Предварительное обучение): Человек тратит 20 лет, чтобы прочитать абсолютно все книги в Британской библиотеке. Теперь он знает все факты, все стили, всю грамматику. Он невероятно эрудирован, но немного "не от мира сего" и не очень хорошо понимает, как общаться с людьми.
Fine-tuning (Дообучение): Этот же человек идет на шестимесячные курсы, чтобы стать юристом (или врачом, или программистом). Ему не нужно заново учить язык — он использует свои гигантские знания и учится применять их для решения конкретных юридических задач, составления исков и консультирования клиентов. Он становится специалистом.

Tr

Часть 1: Pre-training (Предварительное обучение) — "Прочитать всю библиотеку мира"

Что это такое?

Как это происходит на практике?

Пример: Модель видит фразу: "Солнце светит очень ____, поэтому надень очки".
Она пытается предсказать пропущенное слово. Сначала ее догадки случайны: "грустно", "синий", "ярко".
После каждой попытки ей показывают правильный ответ ("ярко") и она немного корректирует свои внутренние параметры (миллиарды связей между нейронами), чтобы в следующий раз быть чуть точнее.

После "очень" часто идет наречие.
"Солнце" и "очки" связаны по смыслу.
Она изучает факты (например, что столица Франции — Париж, потому что эти слова часто встречаются вместе в определенном контексте).
Она учится стилю, читая и стихи, и научные статьи, и посты из соцсетей.

На каких данных это делается?

На всем, что человечество написало и выложило в цифровом виде. Это колоссальный объем данных:

Весь интернет: Огромные срезы интернета, такие как набор данных Common Crawl, который содержит петабайты веб-страниц.
Книги: Миллионы оцифрованных книг со всего мира.
Википедия: Вся Википедия на множестве языков — концентрированный источник фактов.
Научные статьи, новостные архивы, программный код (GitHub) и многое другое.

Часть 2: Fine-tuning (Дообучение) — "Пройти курс по конкретной профессии"

Что это такое?

Как это происходит на практике?

Теперь модель учат на примерах в формате "вопрос-ответ" или "инструкция-результат".

Пример: Мы показываем модели тысячи примеров диалогов:
- Инструкция: "Переведи 'Hello, world!' на французский".
- Правильный ответ: "Bonjour, le monde!".
- Инструкция: "Напиши короткое стихотворение о луне".
- Правильный ответ: (красивое стихотворение о луне).
- Инструкция: "Объясни, что такое фотосинтез, простыми словами".
- Правильный ответ: (понятное объяснение).

Для чего это нужно?

Дообучение позволяет "специализировать" модель:

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

Итог аналогии

Pre-training (Предварительное обучение): Человек тратит 20 лет, чтобы прочитать абсолютно все книги в Британской библиотеке. Теперь он знает все факты, все стили, всю грамматику. Он невероятно эрудирован, но немного "не от мира сего" и не очень хорошо понимает, как общаться с людьми.
Fine-tuning (Дообучение): Этот же человек идет на шестимесячные курсы, чтобы стать юристом (или врачом, или программистом). Ему не нужно заново учить язык — он использует свои гигантские знания и учится применять их для решения конкретных юридических задач, составления исков и консультирования клиентов. Он становится специалистом.

Интеграции и очереди в GCP

Cloud Pub/Sub

Cloud Pub/Sub - управляемый сервис для асинхронного обмена сообщениями между приложениями. Основан на паттерне издатель-подписчик для разделения компонентов системы.

Основные концепции

Топик (Topic) - именованный канал для отправки сообщений. Издатели отправляют сообщения в топик без знания о том, кто их получит.

Подписка (Subscription) - именованная связь между топиком и приложением-подписчиком. Определяет способ доставки сообщений.

Сообщение (Message) - данные и атрибуты, отправляемые в топик. Максимальный размер 10 МБ. Включает payload, атрибуты и уникальный ID.

Издатель (Publisher) - приложение, отправляющее сообщения в топик.

Подписчик (Subscriber) - приложение, получающее сообщения из подписки.

Ключевые характеристики

Гарантии доставки:

At-least-once delivery - каждое сообщение доставляется минимум один раз
Возможны дубликаты, поэтому обработка должна быть идемпотентной
Сообщения хранятся до 7 дней до подтверждения получения

Масштабируемость:

Автоматическое горизонтальное масштабирование
Нет ограничений по количеству издателей или подписчиков
Throughput ограничен только квотами проекта

Упорядочивание:

Global ordering не гарантируется по умолчанию
Ordering keys позволяют сохранить порядок для сообщений с одним ключом
Partition assignment для load balancing

# Создание топика и подписки
gcloud pubsub topics create order-events
gcloud pubsub subscriptions create order-processor \
  --topic=order-events \
  --ack-deadline=60 \
  --message-retention-duration=7d

Push vs Pull подписки

Pull подписки

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

Преимущества Pull:

Контроль скорости - приложение само определяет темп обработки
Batch обработка - возможность получать и обрабатывать группы сообщений
Безопасность - не требует публично доступного endpoint
Flexibility - работает в любой среде, включая on-premises
Backpressure handling - естественная защита от перегрузки

Недостатки Pull:

Сложность кода - необходимость управления polling циклом
Latency - задержки при низком трафике из-за polling intervals
Resource usage - постоянные connections и CPU для polling

Когда использовать Pull:

High-throughput системы с batch обработкой
Приложения за firewall или в закрытых сетях
Необходимость точного контроля над consumption rate
Complex business logic с длительной обработкой

Push подписки

Механизм работы: Pub/Sub активно отправляет HTTP POST запросы на указанный endpoint с сообщениями. Endpoint должен отвечать кодами 2xx для подтверждения получения.

Преимущества Push:

Простота - нет необходимости в polling логике
Real-time - мгновенная доставка сообщений
Serverless friendly - идеально для Cloud Run, Functions
Auto-retry - встроенные механизмы повтора с exponential backoff
Auto-scaling - масштабирование на основе входящих сообщений

Недостатки Push:

Endpoint требования - нужен публично доступный HTTPS endpoint
Rate limiting - ограниченный контроль над скоростью доставки
Security complexity - необходимость аутентификации webhook
Network dependency - зависимость от стабильности сети

Когда использовать Push:

Serverless архитектуры (Cloud Run, Cloud Functions)
Real-time уведомления и алерты
Простые event handlers без complex логики
Микросервисы с REST API

# Push подписка с аутентификацией
gcloud pubsub subscriptions create order-webhook \
  --topic=order-events \
  --push-endpoint=https://api.company.com/webhook/orders \
  --push-auth-service-account=webhook-sa@project.iam.gserviceaccount.com

Настройка обработки сообщений

Acknowledgment (подтверждение):

ack() - сообщение обработано успешно, удалить из очереди
nack() - сообщение не обработано, вернуть в очередь для повтора
ack deadline - максимальное время на обработку, после которого сообщение возвращается в очередь

Flow control:

maxExtensionPeriod - максимальное время продления ack deadline
parallelPullCount - количество concurrent pull операций
maxOutstandingElementCount - максимум необработанных сообщений

Dead Letter Queues (DLQ)

Dead Letter Queue - специальный топик для сообщений, которые не удалось обработать после нескольких попыток.

Принцип работы DLQ

Автоматическое перенаправление: После достижения максимального количества попыток доставки (max-delivery-attempts) сообщение автоматически отправляется в Dead Letter топик вместо удаления.

Сохранение контекста:

Исходное сообщение и все его атрибуты
Metadata о количестве попыток доставки
Временные метки попыток
Причины неудачной обработки

Мониторинг и алертинг: DLQ служит индикатором проблем в системе. Накопление сообщений в DLQ сигнализирует о:

Ошибках в коде обработчиков
Проблемах с downstream сервисами
Неправильной конфигурации системы
Capacity проблемах

# Настройка DLQ
gcloud pubsub topics create order-events-dlq
gcloud pubsub subscriptions update order-processor \
  --dead-letter-topic=order-events-dlq \
  --max-delivery-attempts=5

Стратегии работы с DLQ

Мониторинг и алертинг:

Настройка Cloud Monitoring метрик для отслеживания количества сообщений в DLQ
Alerting при превышении порогов
Dashboard для визуализации DLQ здоровья

Анализ и диагностика:

Регулярный анализ типов ошибок в DLQ
Categorization сообщений по причинам сбоя
Выявление patterns и trends в failures

Reprocessing стратегии:

Manual reprocessing после исправления ошибок
Automated retry с исправленной логикой
Data enrichment или transformation перед повтором

Архивирование:

Перенос старых DLQ сообщений в Cold Storage
Compliance требования для audit trails
Cleanup policies для управления размером DLQ

Cloud Tasks

Cloud Tasks - управляемый сервис для выполнения асинхронных задач с гарантированной доставкой и advanced retry механизмами.

Ключевые отличия от Pub/Sub

Cloud Tasks особенности:

Exactly-once execution при idempotent handlers
Explicit scheduling - задачи можно запланировать на будущее время
Task management - возможность отменить, изменить или получить информацию о задаче
Rate limiting - настройка throughput на уровне очереди
HTTP-centric - ориентирован на HTTP endpoints

Pub/Sub особенности:

At-least-once delivery с возможными дубликатами
Fan-out messaging - одно сообщение для multiple подписчиков
Real-time streaming - немедленная доставка сообщений
Event-driven - реакция на события в реальном времени

Архитектурные применения

Workflow orchestration: Cloud Tasks идеально подходит для реализации сложных business workflows где важен порядок выполнения и возможность отслеживания прогресса.

Background job processing:

Обработка изображений и медиа файлов
Генерация отчетов и документов
Импорт/экспорт данных
Email campaigns и bulk notifications

Scheduled operations:

Future delivery для time-sensitive операций
Reminder systems и notifications
Delayed processing workflows
Cleanup и maintenance задачи

# Создание очереди с rate limiting
gcloud tasks queues create email-queue \
  --max-dispatches-per-second=50 \
  --max-concurrent-dispatches=10 \
  --max-attempts=3

Управление задачами

Task lifecycle:

Created - задача создана и помещена в очередь
Dispatched - задача отправлена на execution
Succeeded - получен HTTP 2xx response
Failed - получен HTTP 4xx/5xx response или timeout
Retrying - задача планируется для повтора

Retry policies:

Exponential backoff с configurable parameters
Max attempts для предотвращения бесконечных повторов
Min/max backoff для контроля intervals между попытками
Retry conditions - retry только для specific HTTP codes

Task routing:

Named tasks для idempotency и deduplication
Task tags для группировки и filtering
Priority levels для important tasks

Cloud Scheduler

Cloud Scheduler - полностью управляемый cron сервис для запуска jobs по расписанию с enterprise-grade reliability.

Планирование задач

Cron syntax: Поддерживает стандартный Unix cron формат с расширениями:

Стандартные поля: минута, час, день месяца, месяц, день недели
Timezone support для global deployments
Flexible expressions для complex schedules

Target types:

HTTP/HTTPS endpoints - прямые REST API calls
Pub/Sub topics - publishing scheduled events
App Engine applications - legacy App Engine handlers

Reliability features:

Automatic retry при failures с configurable policies
Job history и detailed logging для audit
Monitoring integration с Cloud Monitoring
High availability across multiple zones

# Ежедневные отчеты в 9:00 EST
gcloud scheduler jobs create http daily-reports \
  --schedule="0 9 * * *" \
  --uri="https://api.company.com/reports/daily" \
  --time-zone="America/New_York" \
  --http-method=POST

Паттерны использования

Maintenance operations:

Database cleanup и optimization jobs
Log rotation и archiving
Cache warming и preloading
System health checks и monitoring

Business processes:

Financial reporting cycles
Billing и subscription management
Marketing campaign triggers
Data synchronization между системами

Integration с другими сервисами:

Scheduler + Tasks - создание задач в Cloud Tasks для complex workflows
Scheduler + Pub/Sub - triggering event-driven processes
Scheduler + Functions - executing serverless business logic

Eventarc

Eventarc - event routing сервис для построения event-driven архитектур, соединяющий события из различных источников с обработчиками.

Источники событий

Google Cloud сервисы:

Cloud Storage - object lifecycle events (создание, удаление, изменение metadata)
Cloud SQL - database events, configuration changes, backup completion
Firebase - document updates, user authentication, realtime database changes
Cloud Build - build status changes, artifact publishing, deployment events
BigQuery - job completion, dataset modifications, query results

Audit Log события:

Admin Activity - configuration changes, resource creation/deletion
Data Access - read/write operations на data resources
System Events - automatic operations, system maintenance

Custom события:

Pub/Sub integration - application-generated events
HTTP webhooks - third-party system integrations
API Gateway events - request/response cycle events

Event filtering и routing

Filtering mechanisms: События можно фильтровать по типу, источнику, атрибутам для точной доставки только релевантных событий нужным обработчикам.

CloudEvent standard: Все события преобразуются в CloudEvent формат, обеспечивая стандартизированную структуру для cross-platform compatibility.

Multi-destination routing: Одно событие может trigger несколько обработчиков для реализации fan-out patterns.

# Обработка файлов при загрузке в Storage
gcloud eventarc triggers create file-processor \
  --destination-run-service=image-processor \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=user-uploads"

Integration patterns

Microservices communication: Eventarc позволяет микросервисам взаимодействовать через события без прямых dependencies, улучшая loose coupling.

Data pipeline triggering: Автоматический запуск data processing pipelines при появлении новых данных или завершении upstream процессов.

Compliance и audit: Автоматическая обработка audit events для compliance reporting, security monitoring, и governance.

Архитектурные паттерны

Event Sourcing

Концепция: Хранение всех изменений состояния как sequence of events вместо current state snapshots. События служат single source of truth.

Преимущества:

Complete audit trail - полная история всех изменений
Time travel - возможность восстановить состояние на любой момент времени
Debugging - easier troubleshooting через event replay
Analytics - rich data для business intelligence

GCP реализация:

Pub/Sub для event publishing и distribution
Cloud Storage или Firestore для durable event storage
Cloud Functions для event replay и projection building

CQRS (Command Query Responsibility Segregation)

Принцип разделения: Separation of command operations (write) от query operations (read) с different data models для каждой стороны.

Benefits:

Performance optimization - отдельная оптимизация read и write workloads
Scalability - independent scaling для commands и queries
Security - different access controls для read/write operations

GCP implementation:

Cloud Tasks для command processing
Pub/Sub для event propagation между command и query sides
Separate Cloud SQL instances или different database types

Saga Pattern

Distributed transaction management: Координация long-running business transactions across multiple microservices без global locking.

Choreography approach: События координируют transaction steps. Каждый сервис публикует события после completion своей части.

Orchestration approach: Central orchestrator управляет всем workflow, используя Cloud Tasks для step execution.

Compensation handling: Automatic rollback через compensating actions при failure любого step в saga.

Circuit Breaker

Resilience pattern: Защита от cascading failures в distributed systems через monitoring downstream service health.

States:

Closed - normal operation, requests проходят
Open - failure threshold достигнут, requests блокируются
Half-open - testing phase для recovery detection

GCP integration:

Cloud Monitoring для failure rate tracking
Pub/Sub для fallback event publishing
Application-level implementation в microservices

Event Replay и Recovery

Business continuity: Возможность replay events для recovery после outages или для testing новой business logic.

Implementation strategies:

Checkpoint-based replay - restore state from known good checkpoint
Full replay - reprocess all events from beginning
Selective replay - replay specific event types или time ranges

Data consistency: Ensuring eventual consistency across all services после replay completion.

Мониторинг и Observability

Ключевые метрики

Throughput metrics:

Messages per second для Pub/Sub topics
Task execution rate для Cloud Tasks queues
Event processing latency в Eventarc triggers

Error metrics:

Failed message delivery rates
Dead letter queue accumulation
Task retry frequencies и failure patterns

Performance metrics:

End-to-end processing latency
Queue depth и backlog size
Resource utilization patterns

Alerting стратегии

Proactive monitoring:

Dead letter queue accumulation alerts
Processing lag alerts когда queues растут
Error rate threshold violations
Resource exhaustion warnings

Business impact alerts:

Critical workflow failures
SLA violation warnings
Customer-impacting service degradations

Distributed tracing

Request correlation: Tracking requests across multiple services и async processing stages для complete visibility.

Performance analysis: Identifying bottlenecks в event processing pipelines и optimization opportunities.

Root cause analysis: Quick identification проблемных components при system failures.

Best Practices для Production

Idempotency

Message processing: Ensuring repeated processing одного сообщения не создает side effects или data corruption.

Implementation strategies:

Unique message IDs для duplicate detection
Database constraints для preventing duplicate records
State checking перед processing operations

Error Handling

Graceful degradation: System continues operating с reduced functionality при partial failures.

Retry strategies:

Exponential backoff для transient failures
Circuit breakers для systematic failures
Dead letter queues для manual intervention

Security

Authentication и Authorization:

Service account permissions с principle of least privilege
Message encryption in transit и at rest
Audit logging для compliance requirements

Network security:

VPC private networking для internal communications
IAM policies для resource access control
Webhook authentication для external integrations

Cost Optimization

Resource management:

Appropriate message retention periods
Right-sizing compute resources for processing
Batching strategies для reducing API calls

Monitoring costs:

Regular review storage costs для retained messages
Optimization throughput settings для cost efficiency
Usage analysis для identifying optimization opportunities

Наблюдаемость (Observability)

Основные понятия

Наблюдаемость — способность понимать внутреннее состояние системы на основе внешних выходных данных. Включает три основных столпа: логи, метрики и трассировку.

Отличие от мониторинга: мониторинг показывает заранее известные проблемы, наблюдаемость помогает найти неизвестные проблемы через исследование данных.

Google Cloud Platform - Инструменты наблюдаемости

Cloud Logging

Назначение: Централизованное хранение и анализ логов от всех сервисов GCP и пользовательских приложений.

Ключевые возможности:

Автоматический сбор логов от GCP сервисов
Структурированные логи в формате JSON
Поиск по содержимому с использованием фильтров
Интеграция с Cloud Functions для обработки логов в реальном времени

Типы логов:

Audit logs — действия администраторов и API вызовы
Platform logs — системные логи GCP сервисов
Application logs — логи пользовательских приложений

# logging.yaml для Kubernetes
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
data:
  output.conf: |
    [OUTPUT]
    Name stackdriver
    Match *
    google_service_credentials /path/to/credentials.json

Cloud Monitoring

Назначение: Сбор метрик, создание дашбордов и настройка алертов для мониторинга производительности.

Типы метрик:

System metrics — CPU, память, диск, сеть
Application metrics — кастомные метрики приложения
Uptime checks — проверки доступности сервисов
SLI/SLO metrics — метрики уровня сервиса

Источники метрик:

Автоматический сбор от GCP ресурсов
Cloud Monitoring API для кастомных метрик
Prometheus-совместимые метрики
OpenTelemetry интеграция

// Отправка кастомной метрики
import com.google.cloud.monitoring.v3.MetricServiceClient;

MetricServiceClient client = MetricServiceClient.create();
ProjectName projectName = ProjectName.of(projectId);

TimeSeries timeSeries = TimeSeries.newBuilder()
    .setMetric(Metric.newBuilder()
        .setType("custom.googleapis.com/my_metric")
        .putLabels("instance_id", "my-instance"))
    .setResource(MonitoredResource.newBuilder()
        .setType("gce_instance"))
    .addPoints(Point.newBuilder()
        .setValue(TypedValue.newBuilder().setDoubleValue(3.14)))
    .build();

Alerting (Оповещения)

Принципы настройки алертов:

Actionable — алерт должен требовать действий
Relevant — связан с пользовательским опытом
Timely — срабатывает до критических проблем

Типы условий алертов:

Threshold conditions — превышение порогового значения
Absence conditions — отсутствие данных
Rate conditions — скорость изменения метрик

Каналы уведомлений: Email, SMS, Slack, PagerDuty, Webhook

Error Reporting

Назначение: Автоматическая группировка и анализ ошибок в приложениях.

Функциональность:

Автоматическое обнаружение исключений в логах
Группировка похожих ошибок
Статистика частоты и трендов ошибок
Интеграция с системами багтрекинга

Поддерживаемые языки: Java, Python, Node.js, Go, .NET, PHP, Ruby

// Ручная отправка ошибки
import com.google.cloud.errorreporting.v1beta1.ReportErrorsServiceClient;

ReportErrorsServiceClient client = ReportErrorsServiceClient.create();
ReportedErrorEvent errorEvent = ReportedErrorEvent.newBuilder()
    .setMessage("Custom error message")
    .setServiceContext(ServiceContext.newBuilder()
        .setService("my-service")
        .setVersion("1.0.0"))
    .build();

client.reportErrorEvent(ProjectName.of(projectId), errorEvent);

Cloud Trace

Назначение: Распределенная трассировка для анализа производительности микросервисов.

Основные концепции:

Trace — полный путь запроса через систему
Span — отдельная операция внутри trace
Sampling — сбор только части трассировок для снижения нагрузки

Автоматическая трассировка:

App Engine, Cloud Functions, GKE (с Istio)
HTTP библиотеки, база данных, внешние API

Анализ производительности:

Латентность между сервисами
Узкие места в цепочке вызовов
Зависимости между компонентами

// OpenTelemetry трассировка
import io.opentelemetry.api.trace.Tracer;
import io.opentelemetry.api.trace.Span;

Tracer tracer = GlobalOpenTelemetry.getTracer("my-service");
Span span = tracer.spanBuilder("process-order")
    .setAttribute("order.id", orderId)
    .startSpan();
try {
    // бизнес логика
} finally {
    span.end();
}

Cloud Profiler

Назначение: Непрерывное профилирование CPU и памяти в production среде.

Возможности:

Минимальное влияние на производительность (<1% overhead)
Flame graphs для визуализации bottlenecks
Сравнение профилей между версиями
Поддержка Java, Go, Python, Node.js

Типы профилирования:

CPU profiling — где тратится процессорное время
Heap profiling — использование памяти
Contention profiling — блокировки потоков

Cloud Debugger

Назначение: Отладка приложений в production без остановки или замедления.

Функциональность:

Снимки состояния (snapshots) в точках кода
Логпоинты для добавления логирования без деплоя
Просмотр переменных и стека вызовов
Условные точки останова

Ограничения безопасности:

Таймаут на выполнение условий
Лимит на количество снимков
Защита от бесконечных циклов

Экспорт и интеграция данных

Экспорт в BigQuery

Назначение: Долгосрочное хранение и аналитика логов с использованием SQL.

Настройка экспорта:

gcloud logging sinks create my-bigquery-sink \
    bigquery.googleapis.com/projects/PROJECT_ID/datasets/logs_dataset \
    --log-filter='resource.type="gce_instance"'

Преимущества:

Неограниченное время хранения
Мощные аналитические возможности SQL
Интеграция с BI инструментами
Машинное обучение на данных логов

Экспорт в Cloud Storage

Назначение: Архивное хранение логов и compliance требования.

Форматы экспорта: JSON, CSV, Avro, Parquet

Стратегии партиционирования:

По времени (день/час)
По сервису или проекту
По уровню логов

Фильтры логов

Синтаксис фильтров:

# По уровню серьезности
severity >= ERROR

# По ресурсу
resource.type = "gce_instance"
resource.labels.instance_id = "my-instance"

# По временному диапазону
timestamp >= "2024-01-01T00:00:00Z"

# Поиск по содержимому
jsonPayload.message:"database connection failed"

# Комбинированные фильтры
severity >= WARNING AND resource.type = "k8s_container"

Расширенные фильтры:

Регулярные выражения
Операторы NOT, AND, OR
Функции для работы с JSON
Фильтрация по меткам

Стратегии мониторинга

SLI/SLO/SLA

Service Level Indicators (SLI) — метрики качества сервиса:

Латентность (95th percentile < 200ms)
Доступность (uptime %)
Пропускная способность (requests/sec)
Качество данных (error rate < 0.1%)

Service Level Objectives (SLO) — целевые значения SLI Service Level Agreements (SLA) — договорные обязательства с пользователями

Error Budget

Концепция: Допустимый процент ошибок, вычисляемый из SLO.

Если SLO доступности = 99.9%, то error budget = 0.1% = 43.2 минуты в месяц

Использование error budget:

Принятие решений о новых релизах
Баланс между стабильностью и скоростью разработки
Приоритизация работы по надежности

Golden Signals

Четыре ключевые метрики:

Latency — время отклика
Traffic — количество запросов
Errors — частота ошибок
Saturation — загруженность ресурсов

Алерты vs Tickets

Алерты (немедленное реагирование):

Нарушение SLO
Критические ошибки
Недоступность сервиса

Tickets (плановая работа):

Превышение error budget
Деградация производительности
Техническая задолженность

Лучшие практики

Структурированное логирование

// Плохо
logger.info("User " + userId + " ordered " + itemCount + " items");

// Хорошо  
logger.info("Order placed", 
    Map.of("userId", userId, 
           "itemCount", itemCount,
           "orderId", orderId));

Корреляционные ID

Назначение: Связывание всех логов одного запроса через микросервисы.

// MDC для correlation ID
MDC.put("correlationId", UUID.randomUUID().toString());
// Все последующие логи будут содержать correlation ID

Sampling стратегии

Head-based sampling — решение на входе:

Простота реализации
Может потерять важные trace

Tail-based sampling — решение после завершения:

Сохранение ошибочных и медленных trace
Сложность реализации

Мониторинг инфраструктуры как кода

# Terraform для алертов
resource "google_monitoring_alert_policy" "high_cpu" {
  display_name = "High CPU Usage"
  conditions {
    display_name = "CPU > 80%"
    condition_threshold {
      filter         = "resource.type=\"gce_instance\""
      comparison     = "COMPARISON_GREATER_THAN"  
      threshold_value = 0.8
      duration       = "300s"
    }
  }
}

Troubleshooting распространенных проблем

Высокая латентность

Cloud Trace — анализ распределения времени
Cloud Profiler — поиск CPU bottlenecks
Database insights — медленные запросы
Network latency — между сервисами

Периодические ошибки

Error Reporting — группировка и частота
Correlation с метриками — нагрузка, ресурсы
Анализ трендов — время суток, дни недели
Dependency analysis — влияние внешних сервисов

Проблемы масштабирования

Resource utilization — CPU, память, диск
Queue depth — очереди сообщений
Connection pooling — база данных
Rate limiting — внешние API

Эта шпаргалка покрывает основные аспекты наблюдаемости в GCP, необходимые Senior Backend разработчику для эффективного мониторинга и отладки распределенных систем.

Безопасность и ключи в GCP

Secret Manager

Secret Manager - полностью управляемый сервис для безопасного хранения конфиденциальных данных (пароли, API ключи, сертификаты).

Основные концепции

Secret - именованный контейнер для конфиденциальной информации. Может содержать multiple версии для rotation.

Secret Version - конкретная версия секрета с immutable данными. Каждая версия имеет уникальный identifier.

Labels - key-value пары для организации и фильтрации секретов. Полезны для группировки по environment, team, application.

Replication - стратегия распределения секретов по регионам для availability и compliance требований.

Архитектурные преимущества

Централизованное управление: Все секреты хранятся в едином месте с consistent access policies, audit logging и lifecycle management.

Интеграция с IAM: Granular permissions на уровне individual secrets или groups. Service accounts могут иметь read-only access к specific секретам.

Автоматическое шифрование: Data encrypted at rest с Google-managed keys или CMEK (Customer-Managed Encryption Keys).

Audit trail: Полное логирование access attempts, включая successful и failed requests для compliance мониторинга.

Версионирование секретов

Version lifecycle:

Enabled - активная версия, доступна для чтения
Disabled - временно недоступна, можно re-enable
Destroyed - необратимо удалена, нельзя восстановить

Version management стратегии:

Latest version - автоматическое использование newest version
Pinned version - explicit версия для deterministic behavior
Gradual rollout - поэтапный переход на новую версию

# Создание секрета и добавление версий
gcloud secrets create db-password --replication-policy="automatic"
echo "new-secure-password" | gcloud secrets versions add db-password --data-file=-

# Получение latest версии
gcloud secrets versions access latest --secret="db-password"

Secret Rotation

Automatic rotation: Integration с Cloud Functions или Cloud Run для automated password rotation. Scheduler triggers rotation process по расписанию.

Rotation strategies:

Blue-Green rotation:

Создание новой версии секрета
Поэтапный rollout на production системы
Валидация работоспособности
Отключение старой версии

Rolling rotation:

Gradual update individual service instances
Health monitoring во время rotation
Rollback capability при проблемах

Manual rotation triggers:

Security incident response
Compliance requirements
Scheduled maintenance windows
Staff changes requiring re-keying

Integration с приложениями

Service account authentication: Applications используют service accounts для access к Secret Manager без embedding credentials в code.

Caching strategies:

TTL-based caching для reducing API calls
Background refresh для seamless secret updates
Circuit breaker для handling Secret Manager outages

Error handling:

Fallback mechanisms при secret unavailability
Graceful degradation для non-critical secrets
Retry logic с exponential backoff

// Java integration example
@Component
public class SecretService {
    
    private final SecretManagerServiceClient client;
    
    public String getSecret(String secretName) {
        String name = SecretVersionName.of(projectId, secretName, "latest").toString();
        AccessSecretVersionResponse response = client.accessSecretVersion(name);
        return response.getPayload().getData().toStringUtf8();
    }
}

Cloud KMS (Key Management Service)

Cloud KMS - управляемый сервис для создания, использования и управления криптографическими ключами.

Иерархия ключей

Key Ring - логическая группировка ключей в specific geographic location. Нельзя удалить после создания.

Crypto Key - именованный объект для группировки versions ключей. Определяет purpose (encryption, signing, MAC).

Key Version - actual криптографический материал. Можно rotate, disable, destroy.

Location - geographic или multi-regional location для key storage и operations.

Типы ключей

Symmetric encryption keys:

Purpose: ENCRYPT_DECRYPT
Algorithm: AES-256
Use cases: Data encryption, database encryption

Asymmetric encryption keys:

Purpose: ASYMMETRIC_DECRYPT
Algorithms: RSA, Elliptic Curve
Use cases: Certificate signing, secure communication

Signing keys:

Purpose: ASYMMETRIC_SIGN
Algorithms: RSA PSS, ECDSA, Ed25519
Use cases: Digital signatures, JWT signing

MAC keys:

Purpose: MAC
Algorithm: HMAC-SHA256
Use cases: Message authentication, API request signing

Key rotation

Automatic rotation:

Configurable rotation period (30 days to 100 years)
New primary version created automatically
Old versions remain available для decryption
Zero-downtime rotation process

Manual rotation:

On-demand rotation for security incidents
Controlled timing для maintenance windows
Integration с CI/CD pipelines

Key version lifecycle:

Primary - используется для new encrypt operations
Enabled - available для decrypt operations
Disabled - temporarily unavailable
Destroyed - cryptographic material deleted

# Создание key ring и crypto key
gcloud kms keyrings create backend-keys --location=global
gcloud kms keys create database-key \
  --keyring=backend-keys \
  --location=global \
  --purpose=encryption

# Настройка automatic rotation
gcloud kms keys update database-key \
  --keyring=backend-keys \
  --location=global \
  --rotation-period=90d

CMEK (Customer-Managed Encryption Keys)

CMEK - использование customer-controlled ключей из Cloud KMS для шифрования данных в GCP сервисах вместо Google-managed ключей.

Поддерживаемые сервисы

Storage services:

Cloud Storage - bucket-level или object-level encryption
Persistent Disks - VM disk encryption
Cloud SQL - database encryption at rest

Data services:

BigQuery - dataset и table encryption
Cloud Spanner - database encryption
Firestore - document encryption

Compute services:

GKE - etcd и application layer secrets encryption
Cloud Run - service encryption

CMEK benefits

Enhanced control:

Customer controls key lifecycle
Ability to revoke access immediately
Independent key rotation schedules
Compliance requirements satisfaction

Security advantages:

Keys stored separately от encrypted data
Hardware Security Module (HSM) protection
Multi-region key replication options
Audit logging для all key operations

Compliance support:

FIPS 140-2 Level 3 compliance
Common Criteria evaluations
Regional data residency requirements
Industry-specific regulations (HIPAA, PCI DSS)

Implementation considerations

Performance impact:

Minimal latency overhead для encrypt/decrypt operations
Network calls к KMS для key operations
Caching mechanisms для frequently used keys

Availability implications:

Dependency на KMS service availability
Regional considerations для key access
Disaster recovery planning

Cost factors:

KMS operations charges
Key storage costs
Network egress для key requests

# CMEK для Cloud Storage bucket
gsutil kms encryption \
  -k projects/PROJECT/locations/LOCATION/keyRings/RING/cryptoKeys/KEY \
  gs://bucket-name

# CMEK для Compute Engine disk
gcloud compute disks create encrypted-disk \
  --kms-key=projects/PROJECT/locations/LOCATION/keyRings/RING/cryptoKeys/KEY \
  --size=100GB

Organization Policy Constraints

Organization Policies - centralized controls для enforcing security и compliance requirements across всей GCP organization.

Типы constraints

Boolean constraints:

Binary enable/disable controls
Examples: Disable VM serial port access, Require OS Login
Enforcement: Applied automatically across all resources

List constraints:

Allowed/denied values lists
Examples: Allowed VM machine types, Restricted service accounts
Flexibility: Allow/deny specific values или patterns

Custom constraints:

CEL expressions для complex business rules
Resource-specific enforcement logic
Conditional policies based на resource attributes

Security-focused policies

Compute security:

Disable VM serial port - предотвращает unauthorized console access
Require Shielded VMs - enforces secure boot и integrity monitoring
Restrict public IP assignment - limits external connectivity
VM external IP access - controls internet-facing instances

IAM controls:

Domain restricted sharing - prevents external domain access
Service account creation - limits who can create service accounts
Uniform bucket-level access - enforces consistent Cloud Storage permissions

Network security:

Restrict VPC peering - controls network connectivity
Skip default network creation - requires explicit network design
Restrict protocol forwarding - limits network routing capabilities

Implementation strategy

Hierarchical inheritance: Policies применяются на Organization level и наследуются folders и projects. Lower-level policies могут только strengthen restrictions.

Policy evaluation:

Explicit deny overrides any allow
Inheritance chain evaluation от organization к resource
Effective policy combination всех applicable constraints

Rollout approach:

Testing environment validation
Phased deployment по organizational units
Monitoring и adjustment based на operational impact

# Создание organization policy
gcloud resource-manager org-policies set-policy policy.yaml \
  --organization=ORGANIZATION_ID

# Example policy YAML
# constraint: constraints/compute.disableSerialPortAccess
# booleanPolicy:
#   enforced: true

Exception management

Policy exemptions:

Temporary exceptions для migration periods
Service-specific exemptions для legacy systems
Emergency procedures для incident response

Monitoring compliance:

Policy Analyzer для identifying violations
Asset Inventory для compliance reporting
Audit logs для policy enforcement tracking

Security Command Center (SCC)

Security Command Center - centralized security management platform для visibility, threat detection и compliance monitoring.

Core capabilities

Asset Discovery:

Inventory management всех GCP resources
Configuration assessment для security misconfigurations
Change tracking для monitoring resource modifications
Dependency mapping для understanding resource relationships

Vulnerability Assessment:

OS vulnerability scanning для VM instances
Container image scanning в Artifact Registry
Web application scanning через Cloud Security Scanner
Database vulnerability assessment

Threat Detection:

Anomaly detection в user behavior и resource access
Malware detection в storage systems
DDoS attack identification
Suspicious network activity monitoring

Findings management

Finding types:

Security misconfigurations - open firewall rules, public buckets
Vulnerabilities - unpatched software, weak configurations
Threats - malicious activity, policy violations
Compliance violations - regulatory requirement breaches

Severity levels:

Critical - immediate attention required
High - significant risk, prompt action needed
Medium - moderate risk, should be addressed
Low - minor issues, address when convenient

Finding lifecycle:

Active - issue exists и requires attention
Inactive - issue resolved или no longer applicable
Muted - acknowledged but intentionally not addressed

Security insights

Risk assessment:

Security posture scoring для projects и organization
Trend analysis для security improvement tracking
Benchmark comparison против industry standards
Compliance dashboards для regulatory reporting

Recommendation engine:

Automated remediation suggestions
Priority-based action plans
Cost-benefit analysis для security investments
Integration с Security Tools

Integration и automation

SIEM integration:

Export findings к external security platforms
Real-time streaming через Pub/Sub
API access для custom integrations
Webhook notifications для automated responses

Incident response:

Automated playbooks для common security scenarios
Escalation procedures based на finding severity
Collaboration tools integration для team coordination

# Создание SCC notification
gcloud scc notifications create security-alerts \
  --organization=ORGANIZATION_ID \
  --description="Critical security findings" \
  --pubsub-topic=projects/PROJECT/topics/security-notifications \
  --filter='severity="CRITICAL"'

Shielded VMs

Shielded VMs - hardened VM instances с additional security features для защиты от rootkits, bootkits и других low-level attacks.

Security features

Secure Boot:

UEFI firmware verification при startup
Boot loader integrity checking
Operating system kernel verification
Protection против boot-level malware

Measured Boot:

Boot sequence measurements stored в virtual TPM
Integrity attestation для remote verification
Boot log analysis для detecting tampering
Cloud monitoring integration для automated alerts

vTPM (Virtual Trusted Platform Module):

Hardware-based security simulation
Cryptographic key storage для secrets protection
Attestation capabilities для trust verification
Integration с OS security features

Implementation benefits

Enhanced security posture:

Protection против sophisticated attacks
Compliance с security frameworks (NIST, CIS)
Reduced attack surface через hardening
Proactive threat detection

Operational advantages:

Transparent operation - no application changes required
Performance optimization через hardware acceleration
Simplified compliance через built-in security features
Integration с existing monitoring tools

Configuration и monitoring

Security policies:

Secure boot requirement enforcement
vTPM enablement по умолчанию
Integrity monitoring activation
Custom policies для specific workloads

Monitoring capabilities:

Boot integrity alerts в Cloud Security Command Center
Performance metrics tracking
Compliance reporting automation
Integration с log analysis tools

# Создание Shielded VM
gcloud compute instances create secure-vm \
  --zone=us-central1-a \
  --machine-type=n1-standard-1 \
  --image-family=ubuntu-2004-lts \
  --image-project=ubuntu-os-cloud \
  --shielded-secure-boot \
  --shielded-vtpm \
  --shielded-integrity-monitoring

Binary Authorization

Binary Authorization - deploy-time security control для ensuring only trusted container images запускаются в GKE clusters.

Attestation framework

Attestors - entities that verify и attest к image security properties:

Build attestors - verify build process integrity
Vulnerability attestors - confirm security scanning completion
Quality attestors - validate testing и code review

Attestations - cryptographic signatures confirming image properties:

Provenance attestations - build source и process verification
Vulnerability attestations - security scan results
Quality attestations - testing и review completion

Policy enforcement

Admission controller:

Pre-deployment verification images против policies
Cryptographic validation attestations
Automatic rejection non-compliant images
Audit logging всех admission decisions

Policy configuration:

Cluster-specific policies для different environments
Project-wide policies для organizational standards
Exception handling для emergency deployments
Gradual rollout capabilities

CI/CD integration

Build pipeline integration:

Automated attestation creation during builds
Multi-stage verification throughout pipeline
Artifact signing с private keys
Metadata tracking для audit trails

Security scanning integration:

Container Vulnerability Scanning integration
Third-party scanner support
Policy-based scan result evaluation
Automated remediation workflows

Deployment workflow

Image verification process:

Container image pushed к registry
Security scans executed automatically
Attestations created by authorized attestors
Policy evaluation при deployment attempt
Admission decision made by Binary Authorization
Deployment proceeds или blocked based на policy

Break-glass procedures:

Emergency deployment capabilities
Temporary policy override options
Enhanced audit logging для exception cases
Post-incident policy review requirements

# Создание attestor
gcloud container binauthz attestors create build-attestor \
  --attestation-authority-note=projects/PROJECT/notes/build-note \
  --attestation-authority-note-project=PROJECT

# Создание policy
gcloud container binauthz policy import policy.yaml

Defense in Depth Strategy

Layered security approach

Infrastructure layer:

Shielded VMs для compute security
VPC security controls и network isolation
IAM permissions с least privilege principle
Organization policies для compliance enforcement

Application layer:

Secret Manager для credentials management
Binary Authorization для container security
Service mesh security (Istio, Anthos Service Mesh)
Application-level authentication и authorization

Data layer:

CMEK для encryption at rest
TLS для encryption in transit
Data Loss Prevention scanning
Access controls на data resources

Monitoring и response

Continuous monitoring:

Security Command Center для threat detection
Cloud Asset Inventory для configuration monitoring
Audit logs analysis для suspicious activity
Real-time alerts на security events

Incident response:

Automated playbooks для common scenarios
Escalation procedures based на threat severity
Forensic capabilities для post-incident analysis
Recovery procedures и business continuity

Compliance и governance

Regulatory compliance:

Organization policies для regulatory requirements
Audit documentation automation
Compliance monitoring dashboards
Regular assessment и remediation

Security governance:

Risk assessment procedures
Security training requirements
Policy review cycles
Vendor security assessment processes

CI/CD и артефакты

Google Artifact Registry

Назначение: Центральный реестр для хранения артефактов приложений - контейнеров, библиотек и зависимостей.

Ключевые концепции

Репозиторий - логическое хранилище для артефактов определенного типа. Каждый репозиторий привязан к конкретному региону и проекту GCP.

Поддерживаемые форматы:

Docker - образы контейнеров для развертывания приложений
Maven - JAR/WAR артефакты для Java приложений
NPM - пакеты Node.js
Python - Python пакеты (pip)
Apt/Yum - системные пакеты Linux

Управление доступом

IAM роли для разработчиков:

artifactregistry.reader - чтение артефактов (для CI/CD и разработчиков)
artifactregistry.writer - публикация артефактов (для CI/CD pipeline)
artifactregistry.admin - полное управление репозиторием

Service Account - специальная учетная запись для автоматизированного доступа из CI/CD систем. Предпочтительнее использовать Workload Identity вместо JSON ключей.

Интеграция с Maven

<!-- Публикация в Artifact Registry -->
<distributionManagement>
    <repository>
        <id>artifact-registry</id>
        <url>artifactregistry://region-maven.pkg.dev/project/repo</url>
    </repository>
</distributionManagement>

Lifecycle политики позволяют автоматически удалять устаревшие версии, экономя место и затраты.

Google Cloud Build

Назначение: Serverless платформа для автоматизации сборки, тестирования и развертывания приложений.

Архитектура сборки

Build Step - атомарная единица выполнения. Каждый шаг запускается в изолированном контейнере. Контейнеры между шагами могут обмениваться данными через общий workspace.

Cloud Builder образы - предустановленные контейнеры с инструментами:

gcr.io/cloud-builders/mvn - Maven для Java проектов
gcr.io/cloud-builders/gradle - Gradle сборщик
gcr.io/cloud-builders/docker - Docker для контейнеризации
gcr.io/cloud-builders/gcloud - CLI для взаимодействия с GCP

Триггеры

Push триггер - запускается при изменениях в репозитории. Можно настроить фильтры по веткам, путям файлов, и исключениям.

Pull Request триггер - активируется при создании или обновлении PR. Полезен для проверки кода до мержа.

Tag триггер - срабатывает при создании git тегов. Идеально для релизных сборок.

Manual триггер - ручной запуск с возможностью передачи параметров.

Webhook триггер - интеграция с внешними системами через HTTP callbacks.

Substitutions (Подстановки)

Встроенные переменные автоматически доступны в каждой сборке:

$PROJECT_ID - идентификатор GCP проекта
$BRANCH_NAME - название ветки (для push триггеров)
$COMMIT_SHA - хеш коммита
$SHORT_SHA - сокращенный хеш коммита (первые 7 символов)
$REPO_NAME - имя репозитория
$TAG_NAME - имя тега (для tag триггеров)

Пользовательские substitutions определяются в настройках триггера:

substitutions:
  _ENV: 'staging'
  _REGION: 'europe-west1'
  _REPLICAS: '3'

Конфигурация cloudbuild.yaml

steps:
# Сборка приложения
- name: 'gcr.io/cloud-builders/mvn'
  args: ['clean', 'package', '-DskipTests']
  
# Создание Docker образа
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/app:$SHORT_SHA', '.']
  
# Публикация в Artifact Registry
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/$PROJECT_ID/app:$SHORT_SHA']

timeout: 1200s
options:
  machineType: 'E2_HIGHCPU_8'

Timeout - максимальное время выполнения сборки. По умолчанию 10 минут, можно увеличить до 24 часов.

Machine Type - тип виртуальной машины для сборки. Влияет на производительность и стоимость.

Google Cloud Deploy

Назначение: Управляемый сервис для организации delivery pipeline - автоматизированной доставки приложений через несколько сред.

Основные сущности

Delivery Pipeline - последовательность сред развертывания (например: dev → staging → production). Определяет порядок и правила продвижения релизов.

Target - среда развертывания. Может быть GKE кластером, Cloud Run сервисом, или Compute Engine. Каждый target имеет свою конфигурацию и требования.

Release - конкретная версия приложения, готовая к развертыванию. Создается на основе артефактов из Cloud Build или других источников.

Rollout - процесс развертывания release в конкретный target. Включает валидацию, развертывание и верификацию.

Стратегии развертывания

Standard Deploy - обычное развертывание с заменой предыдущей версии.

Canary Deploy - постепенное развертывание:

Развертывание новой версии для небольшого процента трафика
Мониторинг метрик и ошибок
Автоматическое или ручное увеличение трафика
Полное переключение или откат

Blue-Green Deploy - развертывание в параллельную среду:

Развертывание в "green" среду, пока "blue" обслуживает трафик
Тестирование green среды
Мгновенное переключение трафика
Возможность быстрого отката

Интеграция с Cloud Build

# В cloudbuild.yaml после успешной сборки
- name: 'gcr.io/cloud-builders/gcloud'
  args:

  - 'deploy'
  - 'releases'
  - 'create'
  - 'rel-${SHORT_SHA}'
  - '--delivery-pipeline=my-app-pipeline'
  - '--region=europe-west1'
  - '--images=app=gcr.io/$PROJECT_ID/app:${SHORT_SHA}'

Approval Process - можно настроить обязательные подтверждения перед развертыванием в production среды.

GitHub Actions с OIDC

OIDC (OpenID Connect) - современный протокол аутентификации, позволяющий GitHub Actions безопасно аутентифицироваться в GCP без долгоживущих секретных ключей.

Преимущества OIDC перед Service Account ключами

Безопасность: Нет необходимости хранить и ротировать секретные ключи в GitHub Secrets.

Краткосрочные токены: Автоматически истекают, снижая риски компрометации.

Гранулярный доступ: Можно ограничить доступ по репозиторию, ветке, окружению или типу события.

Audit trail: Все аутентификации логируются с подробной информацией о контексте.

Workload Identity Federation

Workload Identity Pool - логическая группировка внешних identity провайдеров. Позволяет настроить доверие между GitHub и GCP.

Identity Provider - конфигурация для конкретного провайдера (GitHub). Определяет, как маппить claims из GitHub токенов на GCP атрибуты.

Attribute Mapping - правила преобразования claims из GitHub токенов:

google.subject=assertion.sub - основной субъект
attribute.repository=assertion.repository - репозиторий
attribute.ref=assertion.ref - ветка или тег

Настройка OIDC

# Создание Workload Identity Pool
gcloud iam workload-identity-pools create "github-pool" \
  --location="global"

# Создание провайдера
gcloud iam workload-identity-pools providers create-oidc "github-provider" \
  --workload-identity-pool="github-pool" \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository"

# Привязка к Service Account
gcloud iam service-accounts add-iam-policy-binding \
  "github-actions@PROJECT.iam.gserviceaccount.com" \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/NUMBER/locations/global/workloadIdentityPools/github-pool/attribute.repository/owner/repo"

GitHub Actions Workflow

name: Deploy Java App
on:
  push:
    branches: [main]

permissions:
  id-token: write  # Необходимо для OIDC
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:

    - uses: actions/checkout@v4
    
    - name: Authenticate to GCP
      uses: google-github-actions/auth@v1
      with:
        workload_identity_provider: 'projects/123/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
        service_account: 'github-actions@project.iam.gserviceaccount.com'
    
    - name: Setup gcloud
      uses: google-github-actions/setup-gcloud@v1
    
    - name: Build and Deploy
      run: |
        mvn clean package
        gcloud builds submit --tag gcr.io/$PROJECT_ID/app:$GITHUB_SHA

permissions блок критически важен - без id-token: write OIDC аутентификация не работает.

Лучшие практики для Senior Backend

Управление версиями артефактов

Семантическое версионирование (SemVer) для Maven артефактов: MAJOR.MINOR.PATCH

MAJOR - breaking changes в API
MINOR - новая функциональность без breaking changes
PATCH - bug fixes

Теги Docker образов:

Используйте commit SHA для уникальности: app:abc123
Добавляйте семантические теги: app:1.2.3
Обновляйте latest только для stable релизов

Pipeline архитектура

Разделение ответственности:

Build stage - компиляция, unit тесты, создание артефактов
Deploy stage - развертывание в environments
Promote stage - продвижение между средами

Параллелизация: Выносите независимые задачи (линтеры, security сканы, документация) в параллельные джобы.

Кеширование: Настройте кеш для Maven dependencies, Docker layers, node_modules для ускорения сборок.

Безопасность

Принцип минимальных привилегий: Service accounts должны иметь только необходимые роли для конкретных задач.

Сканирование уязвимостей: Интегрируйте в pipeline проверку зависимостей (OWASP Dependency Check) и контейнеров (Container Analysis API).

Secrets management: Используйте Google Secret Manager для хранения паролей, API ключей, сертификатов.

Мониторинг и отладка

Cloud Build логи: Структурированные логи помогают быстро найти причину падения сборки.

Pub/Sub уведомления: Настройте отправку статуса сборок в Slack, email или внешние системы.

Metrics и alerting: Мониторьте время сборок, success rate, использование ресурсов.

Rollback стратегия: Всегда имейте план отката для production развертываний.

Terraform в GCP - Руководство

Провайдеры и аутентификация

Google Provider

Google Provider — основной провайдер для работы с GCP ресурсами. Существует две версии:

google — стабильная версия для GA (Generally Available) ресурсов
google-beta — для beta и alpha функций GCP

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.0"
    }
    google-beta = {
      source  = "hashicorp/google-beta"
      version = "~> 4.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = var.region
}

Методы аутентификации

Service Account Key — файл JSON с ключами сервисного аккаунта:

provider "google" {
  credentials = file("path/to/service-account.json")
  project     = "my-project-id"
}

Application Default Credentials (ADC) — рекомендуемый подход для локальной разработки:

gcloud auth application-default login

Workload Identity — для CI/CD в GKE. Позволяет Kubernetes pods получать токены доступа без явного хранения ключей.

Environment Variables — через переменные окружения:

export GOOGLE_APPLICATION_CREDENTIALS="path/to/key.json"
export GOOGLE_PROJECT="my-project-id"

Организация проекта

Структура окружений (Environments)

Разделение по окружениям через директории — стандартный подход для изоляции dev/staging/prod:

terraform/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   ├── staging/
│   └── prod/
├── modules/
│   ├── vpc/
│   ├── gke/
│   └── cloud-run/
└── shared/
    └── variables.tf

Terraform Workspaces

Workspace — механизм для управления несколькими состояниями в одной конфигурации. Полезен для feature-branches или временных окружений:

terraform workspace new feature-branch
terraform workspace select prod
terraform workspace list

Доступ к имени workspace в коде:

locals {
  env = terraform.workspace
  project_id = "${var.base_project_id}-${local.env}"
}

Remote State в GCS

Google Cloud Storage (GCS) как backend для хранения state файлов обеспечивает:

Централизованное хранение состояния
Версионирование изменений
Блокировки для предотвращения конфликтов

terraform {
  backend "gcs" {
    bucket = "my-terraform-state-bucket"
    prefix = "terraform/state"
  }
}

State Locking — автоматическая блокировка через GCS предотвращает одновременное выполнение terraform операций несколькими пользователями.

Создание bucket для state:

resource "google_storage_bucket" "terraform_state" {
  name     = "my-terraform-state-bucket"
  location = "US"
  
  versioning {
    enabled = true
  }
  
  lifecycle_rule {
    condition {
      num_newer_versions = 5
    }
    action {
      type = "Delete"
    }
  }
}

Ключевые ресурсы GCP

google_project_service

Project Service — включение API сервисов в GCP проекте. Обязательный первый шаг перед использованием любых GCP ресурсов:

resource "google_project_service" "required_apis" {
  for_each = toset([
    "compute.googleapis.com",
    "container.googleapis.com",
    "run.googleapis.com",
    "cloudbuild.googleapis.com"
  ])
  
  service = each.value
  disable_on_destroy = false
}

disable_on_destroy = false предотвращает отключение API при удалении ресурса, что важно для production окружений.

IAM (Identity and Access Management)

IAM в GCP управляет доступом через роли и политики. Основные типы ролей:

Primitive roles — широкие права (Owner, Editor, Viewer)
Predefined roles — готовые роли для сервисов
Custom roles — созданные под конкретные нужды

# Service Account
resource "google_service_account" "app_sa" {
  account_id   = "my-app-sa"
  display_name = "Application Service Account"
  description  = "SA for my application"
}

# Привязка роли к проекту
resource "google_project_iam_member" "app_sa_storage" {
  project = var.project_id
  role    = "roles/storage.objectViewer"
  member  = "serviceAccount:${google_service_account.app_sa.email}"
}

# Создание ключа (не рекомендуется для production)
resource "google_service_account_key" "app_sa_key" {
  service_account_id = google_service_account.app_sa.name
}

Workload Identity — рекомендуемый способ для GKE:

resource "google_service_account_iam_member" "workload_identity" {
  service_account_id = google_service_account.app_sa.name
  role               = "roles/iam.workloadIdentityUser"
  member             = "serviceAccount:${var.project_id}.svc.id.goog[${var.namespace}/${var.ksa_name}]"
}

VPC (Virtual Private Cloud)

VPC — изолированная сетевая среда в GCP. Включает подсети, правила firewall, маршрутизацию:

# VPC Network
resource "google_compute_network" "main" {
  name                    = "main-vpc"
  auto_create_subnetworks = false
  routing_mode           = "REGIONAL"
}

# Subnet
resource "google_compute_subnetwork" "private" {
  name          = "private-subnet"
  ip_cidr_range = "10.0.1.0/24"
  region        = var.region
  network       = google_compute_network.main.id
  
  secondary_ip_range {
    range_name    = "pods"
    ip_cidr_range = "10.1.0.0/16"
  }
  
  secondary_ip_range {
    range_name    = "services"
    ip_cidr_range = "10.2.0.0/16"
  }
}

# Firewall Rules
resource "google_compute_firewall" "allow_internal" {
  name    = "allow-internal"
  network = google_compute_network.main.name
  
  allow {
    protocol = "tcp"
    ports    = ["0-65535"]
  }
  
  source_ranges = ["10.0.0.0/8"]
}

NAT Gateway для исходящего трафика из private сетей:

resource "google_compute_router" "router" {
  name    = "nat-router"
  region  = var.region
  network = google_compute_network.main.id
}

resource "google_compute_router_nat" "nat" {
  name   = "nat-gateway"
  router = google_compute_router.router.name
  region = var.region
  
  nat_ip_allocate_option             = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
}

Load Balancer

Google Cloud Load Balancer — масштабируемое решение для распределения трафика. Типы:

External HTTP(S) LB — глобальный, для веб-приложений
Internal LB — для внутреннего трафика
Network LB — для TCP/UDP трафика

# Backend Service
resource "google_compute_backend_service" "default" {
  name        = "backend-service"
  protocol    = "HTTP"
  timeout_sec = 10
  
  backend {
    group = google_compute_instance_group.webservers.self_link
  }
  
  health_checks = [google_compute_health_check.default.self_link]
}

# URL Map
resource "google_compute_url_map" "default" {
  name            = "url-map"
  default_service = google_compute_backend_service.default.self_link
}

# HTTP Proxy
resource "google_compute_target_http_proxy" "default" {
  name   = "http-proxy"
  url_map = google_compute_url_map.default.self_link
}

# Forwarding Rule
resource "google_compute_global_forwarding_rule" "default" {
  name       = "forwarding-rule"
  target     = google_compute_target_http_proxy.default.self_link
  port_range = "80"
}

Cloud Run

Cloud Run — serverless платформа для контейнеризованных приложений. Автоматическое масштабирование от 0 до N экземпляров:

resource "google_cloud_run_service" "default" {
  name     = "my-service"
  location = var.region
  
  template {
    spec {
      containers {
        image = "gcr.io/${var.project_id}/my-app:latest"
        
        env {
          name  = "ENV"
          value = "production"
        }
        
        resources {
          limits = {
            cpu    = "1000m"
            memory = "512Mi"
          }
        }
      }
      
      service_account_name = google_service_account.app_sa.email
    }
    
    metadata {
      annotations = {
        "autoscaling.knative.dev/maxScale" = "100"
        "run.googleapis.com/cpu-throttling" = "false"
      }
    }
  }
  
  traffic {
    percent         = 100
    latest_revision = true
  }
}

# IAM для публичного доступа
resource "google_cloud_run_service_iam_member" "public" {
  service  = google_cloud_run_service.default.name
  location = google_cloud_run_service.default.location
  role     = "roles/run.invoker"
  member   = "allUsers"
}

GKE (Google Kubernetes Engine)

GKE — управляемый Kubernetes сервис. Основные компоненты:

Cluster — control plane + node pools
Node Pool — группа worker nodes с одинаковой конфигурацией
Workload Identity — интеграция с GCP IAM

resource "google_container_cluster" "primary" {
  name     = "gke-cluster"
  location = var.region
  
  # Autopilot или Standard режим
  enable_autopilot = false
  
  # Удаление default node pool
  remove_default_node_pool = true
  initial_node_count       = 1
  
  network    = google_compute_network.main.name
  subnetwork = google_compute_subnetwork.private.name
  
  # IP ranges для pods и services
  ip_allocation_policy {
    cluster_secondary_range_name  = "pods"
    services_secondary_range_name = "services"
  }
  
  # Workload Identity
  workload_identity_config {
    workload_pool = "${var.project_id}.svc.id.goog"
  }
  
  # Настройки безопасности
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }
  
  master_authorized_networks_config {
    cidr_blocks {
      cidr_block   = "0.0.0.0/0"
      display_name = "All"
    }
  }
}

# Node Pool
resource "google_container_node_pool" "primary_nodes" {
  name       = "primary-pool"
  location   = var.region
  cluster    = google_container_cluster.primary.name
  node_count = 1
  
  node_config {
    preemptible  = true
    machine_type = "e2-medium"
    
    service_account = google_service_account.gke_sa.email
    oauth_scopes = [
      "https://www.googleapis.com/auth/cloud-platform"
    ]
    
    workload_metadata_config {
      mode = "GKE_METADATA"
    }
  }
  
  autoscaling {
    min_node_count = 1
    max_node_count = 10
  }
  
  management {
    auto_repair  = true
    auto_upgrade = true
  }
}

Best Practices

Labeling Strategy

Labels — ключевой механизм для управления ресурсами и cost tracking. Стандартные лейблы:

locals {
  common_labels = {
    environment = var.environment
    project     = var.project_name
    managed_by  = "terraform"
    team        = var.team
    cost_center = var.cost_center
  }
}

resource "google_compute_instance" "web" {
  name = "web-server"
  
  labels = merge(local.common_labels, {
    role = "webserver"
    tier = "frontend"
  })
}

Outputs

Outputs — способ передачи данных между модулями и получения информации после применения:

output "cluster_endpoint" {
  description = "GKE cluster endpoint"
  value       = google_container_cluster.primary.endpoint
  sensitive   = true
}

output "service_account_email" {
  description = "Email of the service account"
  value       = google_service_account.app_sa.email
}

output "vpc_self_link" {
  description = "VPC self link for cross-module reference"
  value       = google_compute_network.main.self_link
}

Variables Design

Принцип минимальности — только необходимые переменные с разумными default значениями:

variable "project_id" {
  description = "GCP Project ID"
  type        = string
}

variable "region" {
  description = "GCP region"
  type        = string
  default     = "us-central1"
}

variable "environment" {
  description = "Environment name"
  type        = string
  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

Import существующих ресурсов

Import — добавление существующих GCP ресурсов под управление Terraform:

# Импорт проекта
terraform import google_project.my_project my-project-id

# Импорт VPC
terraform import google_compute_network.main projects/my-project/global/networks/my-vpc

# Импорт GKE кластера
terraform import google_container_cluster.primary projects/my-project/locations/us-central1/clusters/my-cluster

После импорта необходимо привести конфигурацию в соответствие с существующим ресурсом.

Модульность

Модули — переиспользуемые компоненты инфраструктуры. Структура модуля:

modules/gke/
├── main.tf      # Основные ресурсы
├── variables.tf # Входные параметры
├── outputs.tf   # Выходные значения
└── versions.tf  # Требования провайдеров

Использование модуля:

module "gke" {
  source = "./modules/gke"
  
  project_id    = var.project_id
  cluster_name  = "prod-cluster"
  node_count    = 3
  machine_type  = "e2-standard-4"
  
  labels = local.common_labels
}

Управление состоянием

State management — критически важные практики:

Remote state обязателен для team работы
State locking предотвращает конфликты
Backup state файлов через versioning
Разделение state по окружениям/компонентам

# Отдельный state для каждого компонента
terraform {
  backend "gcs" {
    bucket = "terraform-state-bucket"
    prefix = "networking/vpc"  # Отдельный prefix для VPC
  }
}

Security Best Practices

Принцип наименьших привилегий — минимальные необходимые права:

# Вместо Editor используем конкретные роли
resource "google_project_iam_member" "app_storage" {
  project = var.project_id
  role    = "roles/storage.objectViewer"  # Не Admin
  member  = "serviceAccount:${google_service_account.app.email}"
}

Secrets management — через Secret Manager, не в коде:

resource "google_secret_manager_secret" "db_password" {
  secret_id = "db-password"
  
  replication {
    automatic = true
  }
}

Network security — private clusters и minimal firewall rules:

resource "google_compute_firewall" "restricted" {
  name    = "allow-specific-ports"
  network = google_compute_network.main.name
  
  allow {
    protocol = "tcp"
    ports    = ["80", "443", "22"]  # Только необходимые порты
  }
  
  source_ranges = ["10.0.0.0/8"]  # Конкретные CIDR
  target_tags   = ["webserver"]
}

Биллинг и оптимизация стоимости в Google Cloud Platform

Budgets & Alerts (Бюджеты и уведомления)

Cloud Billing Budgets

Назначение: Инструмент для установки лимитов расходов и автоматического мониторинга затрат по проектам, сервисам или меткам.

Основные возможности:

Установка месячных/квартальных лимитов расходов
Уведомления при достижении 50%, 90%, 100% бюджета
Интеграция с Cloud Pub/Sub для автоматизации действий
Фильтрация по проектам, сервисам, SKU, метками

Типы бюджетов:

Фиксированный: точная сумма ($1000/месяц)
Процентный: от предыдущего периода (110% от прошлого месяца)
Планируемый: на основе прогнозов использования

# Создание бюджета через gcloud CLI
gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="Production Budget" \
  --budget-amount=1000USD \
  --threshold-percent=50,90,100

Programmatic Budget Alerts

Автоматизация действий при превышении бюджета:

Отключение Compute Engine инстансов
Остановка Cloud Run сервисов
Масштабирование вниз Kubernetes кластеров

Cost Breakdown (Разбивка затрат)

Cloud Billing Reports

Детализация расходов по различным измерениям:

По времени: почасовая, дневная, месячная аналитика
По проектам: изоляция затрат между командами/средами
По сервисам: Compute Engine, BigQuery, Cloud Storage и т.д.
По SKU: конкретные типы ресурсов (n1-standard-1, pd-ssd)
По меткам: custom labels для бизнес-логики группировки

Cloud Asset Inventory

Инвентаризация ресурсов для анализа неиспользуемых активов:

Orphaned диски (отсоединенные от VM)
Неактивные IP адреса
Пустые Load Balancers
Неиспользуемые Cloud SQL инстансы

# Поиск неприсоединенных дисков
gcloud compute disks list --filter="users:(*) AND -users:*"

FinOps Integration

Интеграция с бизнес-процессами:

Chargeback модели для внутреннего биллинга
Showback отчеты для команд разработки
Resource Hierarchy для организационной структуры

Скидки и оптимизация

Committed Use Discounts (CUDs)

Долгосрочные обязательства со скидками до 57%:

Compute Engine CUDs:

1 год: скидка 25-35%
3 года: скидка 52-57%
Привязка к региону и типу машины
Автоматическое применение к подходящим инстансам

Memory-optimized и GPU CUDs:

Отдельные commitment для high-memory воркloadов
GPU commitments для ML/AI задач

# Покупка CUD commitment
gcloud compute commitments create my-commitment \
  --plan=12-month \
  --resources=vcpu=100,memory=400GB \
  --region=us-central1

Spot/Preemptible Instances

Временные инстансы со скидкой до 91%:

Spot VM: новое поколение preemptible с улучшенной предсказуемостью
Preemptible VM: могут быть прерваны в любой момент
Ideal для: batch processing, CI/CD, stateless приложений

Лучшие практики:

Graceful shutdown handling через metadata signals
Checkpointing для долгих вычислений
Fault-tolerant архитектура

Sustained Use Discounts

Автоматические скидки за продолжительное использование:

25% скидка при использовании >25% месяца
Применяется автоматически
Работает для Compute Engine и GKE nodes

Autoscaling оптимизация

Compute Engine Autoscaling

Managed Instance Groups (MIG) с intelligent scaling:

CPU utilization: масштабирование по нагрузке процессора
Load balancing utilization: по нагрузке на балансировщик
Custom metrics: по метрикам приложения из Cloud Monitoring
Predictive autoscaling: ML-based прогнозирование нагрузки

# Autoscaling policy пример
autoscaling:
  minNumReplicas: 2
  maxNumReplicas: 10
  cpuUtilization:
    utilizationTarget: 0.6
  customMetricUtilizations:

  - metric: "pubsub.googleapis.com/subscription/num_undelivered_messages"
    utilizationTarget: 100

Google Kubernetes Engine (GKE) Autoscaling

Многоуровневое масштабирование:

Horizontal Pod Autoscaler (HPA):

Масштабирование подов по CPU/memory/custom metrics
Интеграция с Stackdriver для внешних метрик

Vertical Pod Autoscaler (VPA):

Автоматическая настройка CPU/memory requests
Recommendation mode для анализа оптимальных ресурсов

Cluster Autoscaler:

Автоматическое добавление/удаление нод
Spot nodes integration для cost optimization

Node Auto Provisioning (NAP):

Автоматический выбор оптимальных типов машин
Смешивание spot и regular nodes

Cloud Run concurrency

Concurrency Settings

Оптимизация стоимости через настройку параллелизма:

Container Concurrency:

Значение по умолчанию: 1000 concurrent requests на instance
Низкая concurrency (1-10): для CPU-intensive задач
Высокая concurrency (100-1000): для I/O-intensive задач

CPU Allocation:

CPU always allocated: для постоянной нагрузки
CPU only during requests: для спорадических запросов (экономия до 50%)

# Cloud Run service configuration
apiVersion: serving.knative.dev/v1
kind: Service
spec:
  template:
    metadata:
      annotations:
        run.googleapis.com/cpu-throttling: "false"
        autoscaling.knative.dev/maxScale: "100"
    spec:
      containerConcurrency: 80
      containers:

      - image: gcr.io/project/image
        resources:
          limits:
            cpu: "1"
            memory: "512Mi"

Request-based Scaling

Автоматическое масштабирование на основе трафика:

Scale-to-zero: automatic shutdown при отсутствии запросов
Cold start optimization: минимизация времени запуска
Min instances: предотвращение cold starts для критичных сервисов

BigQuery оптимизация

Query Optimization

Основные источники затрат в BigQuery:

Data Processing Costs:

On-demand pricing: $5 за TB обработанных данных
Flat-rate pricing: фиксированная стоимость для предсказуемых workloads
BI Engine: in-memory analytics для dashboard queries

Optimization Techniques:

Partitioning: по времени для фильтрации данных
Clustering: группировка часто запрашиваемых колонок
Column pruning: выбор только необходимых колонок
Query caching: 24-часовое кеширование результатов

-- Пример оптимизированного запроса
SELECT 
  customer_id, 
  SUM(amount) as total
FROM `project.dataset.sales_partitioned`
WHERE DATE(created_at) >= '2024-01-01'  -- Партиционирование по дате
  AND region = 'US'  -- Кластеризация по региону
GROUP BY customer_id

Storage Optimization

Уровни хранения с разной стоимостью:

Active storage: $0.02/GB для часто используемых данных
Long-term storage: $0.01/GB для данных старше 90 дней
Archive storage: для compliance и backup данных

Data Lifecycle Management

Автоматизация перемещения данных между уровнями:

Table expiration settings
Partition expiration для time-partitioned таблиц
Export в Cloud Storage для архивирования

Network Egress оптимизация

Egress Pricing Structure

Тарификация исходящего трафика:

В пределах зоны: бесплатно
Между зонами региона: $0.01/GB
Между регионами: $0.05-0.12/GB
Internet egress: $0.12-0.23/GB (зависит от объема)

Optimization Strategies

Архитектурные решения для минимизации egress:

Regional Colocation:

Размещение связанных сервисов в одном регионе
Использование региональных Persistent Disks

Private Google Access:

Доступ к Google APIs без интернет egress
VPC peering вместо интернет-маршрутизации

Content Delivery:

Cloud CDN для статического контента
Edge caching для уменьшения origin traffic

# Анализ egress трафика
gcloud logging read "resource.type=gce_instance" \
  --format="table(httpRequest.remoteIp, httpRequest.responseSize)"

Cloud CDN оптимизация

Caching Strategy

Многоуровневое кеширование для снижения costs:

Edge Caching:

Global edge locations: 130+ точек присутствия
Cache hit ratio: оптимизация до 95%+ для статики
Smart routing: автоматический выбор ближайшего edge

Cache Configuration:

TTL settings: оптимальное время жизни кеша
Cache keys: настройка на основе headers/query params
Negative caching: кеширование 404/503 ответов

# Cloud CDN configuration
backendBuckets:
  cdnPolicy:
    cacheMode: "CACHE_ALL_STATIC"
    defaultTtl: 3600
    maxTtl: 86400
    negativeCaching: true
    negativeCachingPolicy:

    - code: 404
      ttl: 300

Compression & Optimization

Автоматическая оптимизация контента:

Gzip compression: автоматическое сжатие текстового контента
Brotli compression: улучшенное сжатие для современных браузеров
Image optimization: автоматическое изменение размера изображений

Monitoring & Analytics

Отслеживание эффективности CDN:

Cache hit ratio: процент запросов из кеша
Origin latency: время ответа origin серверов
Egress reduction: экономия на исходящем трафике

Cost Monitoring & Governance

Cloud Billing API

Программный доступ к данным о расходах:

Real-time cost tracking
Integration с внутренними системами
Automated cost allocation

Recommender API

ML-powered рекомендации по оптимизации:

Rightsizing VM instances
Idle resource detection
Commitment recommendations
Security recommendations

Organization Policies

Governance controls для cost management:

Resource location restrictions
VM machine type constraints
External IP usage policies
Automatic deletion policies

# Пример Organization Policy
name: "projects/PROJECT_ID/policies/compute.vmExternalIpAccess"
spec:
  rules:

  - denyAll: true  # Запрет external IP для экономии

Практические рекомендации

Cost Optimization Workflow

Регулярные процессы для контроля затрат:

Weekly Cost Reviews: анализ трендов и аномалий
Monthly Rightsizing: оптимизация размеров ресурсов
Quarterly Commitment Reviews: оценка CUD opportunities
Resource Tagging Strategy: consistent labeling для tracking

Emergency Cost Controls

Быстрые действия при превышении бюджета:

Project shutdown scripts: автоматическое отключение non-prod окружений
Resource scheduling: shutdown/startup расписания для dev/test
Spending caps: жесткие лимиты через Organization Policies

Team Education

Best practices для команд разработки:

Cost awareness training
Resource cleanup procedures
Environment-specific guidelines
Cost attribution responsibility

Политики, соответствие и управление в Google Cloud Platform

Resource Manager - Иерархическая структура

Иерархия ресурсов GCP

Организационная структура для управления ресурсами и политиками:

Organization (Организация)
├── Folder (Папка) - Отдел/Команда
│   ├── Folder (Подпапка) - Среда
│   │   ├── Project (Проект) - Приложение/Сервис
│   │   │   └── Resources (Ресурсы)

Ключевые принципы иерархии:

Наследование политик: дочерние узлы наследуют политики родителей
Принцип наименьших привилегий: права назначаются на минимально необходимом уровне
Централизованное управление: политики безопасности управляются на уровне Organization/Folder

Organization Node

Корневой узел для всех ресурсов компании:

Единая точка управления: глобальные политики и настройки
Domain verification: привязка к Google Workspace или Cloud Identity
Billing account association: централизованное управление биллингом
Super Admin роль: полный контроль над всей организацией

Настройка Organization:

Требует Google Workspace или Cloud Identity домен
Автоматически создается при первом логине Super Admin
Нельзя удалить после создания
Единственный способ группировки проектов под общим управлением

Project как единица изоляции

Основная единица развертывания и биллинга:

Resource isolation: полная изоляция сетей, IAM, API
Billing boundary: отдельный биллинг и квоты для каждого проекта
API enablement: сервисы GCP включаются на уровне проекта
Service account scope: Service Accounts принадлежат проекту

Лучшие практики проектов:

Один проект = одна среда (dev/staging/prod)
Отдельные проекты для shared services (monitoring, logging)
Naming convention: company-team-env-app (example: acme-backend-prod-api)

Folder Strategy - Стратегия организации папок

Organizational Folders

Логическая группировка проектов для управления:

Department-based: группировка по отделам (Engineering, Marketing, Finance)
Environment-based: группировка по средам (Development, Staging, Production)
Team-based: группировка по командам (Backend, Frontend, DevOps)
Business-unit-based: группировка по бизнес-юнитам

Folder-level Policies

Политики на уровне папок для унифицированного управления:

IAM inheritance: роли назначаются на папку и наследуются проектами
Organization Policies: ограничения применяются ко всем дочерним ресурсам
Resource quotas: лимиты на использование ресурсов в папке
Audit logging: централизованное логирование для compliance

Примеры политик папок:

Production папка: запрет SSH ключей, обязательные encryption
Development папка: разрешение external IP, relaxed policies
Shared Services: строгие сетевые политики, централизованное управление

Folder Administration

Управление папками и делегирование прав:

Folder Admin: может создавать проекты и управлять IAM в папке
Folder Viewer: read-only доступ к структуре папки
Project Creator: может создавать новые проекты в папке

Tags и Labels - Система меток

Resource Labels

Key-value метки для категоризации и управления ресурсами:

Основные применения:

Cost allocation: распределение затрат между командами/проектами
Resource management: группировка для bulk operations
Compliance tracking: отслеживание соответствия требованиям
Automation: trigger для automated workflows

Рекомендуемые labels:

# Стандартный набор labels
environment: "production"          # dev/staging/prod
team: "backend-api"               # владеющая команда
application: "user-service"       # название приложения
version: "v1.2.3"                # версия приложения
cost-center: "engineering"       # центр затрат
compliance: "pci-dss"            # требования compliance
backup-policy: "daily"           # политика backup

Resource Tags (Beta)

Иерархические метки с наследованием:

Conditional IAM: права доступа на основе тегов
Organization-wide taxonomy: централизованная система классификации
Policy automation: автоматическое применение политик по тегам
Resource discovery: улучшенный поиск и фильтрация

Отличия Tags от Labels:

Tags: управляются централизованно, наследуются, условный IAM
Labels: локальные для ресурса, простые key-value пары

Tagging Strategy

Корпоративная стратегия тегирования:

Обязательные теги:

env/production, env/development
team/backend, team/frontend
data-classification/public, data-classification/confidential

Conditional IAM с тегами:

# Доступ только к production ресурсам для SRE
bindings:

- members: ["group:sre@company.com"]
  role: "roles/compute.admin"
  condition:
    expression: "resource.tags['env'] == 'production'"

Organization Policies - Корпоративные политики

Policy Architecture

Centralized governance через декларативные ограничения:

Constraints: правила, определяющие разрешенное поведение
Policy inheritance: политики наследуются по иерархии ресурсов
Policy evaluation: проверка происходит при создании/изменении ресурсов
Dry-run mode: тестирование политик без применения

Категории Organization Policies

Compute Policies

Ограничения для виртуальных машин:

Запрет External IP адресов:

# constraints/compute.vmExternalIpAccess
constraint: "constraints/compute.vmExternalIpAccess"
listPolicy:
  allValues: "DENY"  # Полный запрет внешних IP

Применение: повышение безопасности, принуждение к использованию NAT Gateway или VPN

Ограничение типов машин:

# constraints/compute.vmCanIpForward
constraint: "constraints/compute.vmCanIpForward"
booleanPolicy:
  enforced: false  # Запрет IP forwarding

Trusted image policy:

# constraints/compute.trustedImageProjects
constraint: "constraints/compute.trustedImageProjects"
listPolicy:
  allowedValues:

  - "projects/debian-cloud"
  - "projects/ubuntu-os-cloud"
  - "projects/company-golden-images"

Service Account Policies

Управление Service Accounts для security compliance:

Запрет создания SA ключей:

# constraints/iam.disableServiceAccountKeyCreation
constraint: "constraints/iam.disableServiceAccountKeyCreation"
booleanPolicy:
  enforced: true  # Запрет JSON ключей SA

Обоснование: JSON ключи представляют security risk, лучше использовать Workload Identity

Ограничение upload SA ключей:

# constraints/iam.disableServiceAccountKeyUpload
constraint: "constraints/iam.disableServiceAccountKeyUpload"  
booleanPolicy:
  enforced: true

Domain restricted sharing:

# constraints/iam.allowedPolicyMemberDomains
constraint: "constraints/iam.allowedPolicyMemberDomains"
listPolicy:
  allowedValues:

  - "company.com"
  - "contractor-company.com"

Storage and Data Policies

Защита данных и compliance требования:

Uniform bucket-level access:

# constraints/storage.uniformBucketLevelAccess
constraint: "constraints/storage.uniformBucketLevelAccess"
booleanPolicy:
  enforced: true  # Принудительное использование IAM для Cloud Storage

Запрет публичных buckets:

# constraints/storage.publicAccessPrevention
constraint: "constraints/storage.publicAccessPrevention"
booleanPolicy:
  enforced: true

Network Security Policies

Сетевая безопасность и изоляция:

Restrict VPC peering:

# constraints/compute.restrictVpcPeering
constraint: "constraints/compute.restrictVpcPeering"
listPolicy:
  allowedValues:

  - "under:organizations/ORG_ID"  # Только внутри организации

SSL policy requirements:

# constraints/compute.requireSslCertificates
constraint: "constraints/compute.requireSslCertificates"
booleanPolicy:
  enforced: true

Policy Implementation Strategy

Phased Rollout

Поэтапное внедрение политик:

Discovery Phase: анализ текущего состояния ресурсов
Dry-run Phase: тестирование политик без enforcement
Pilot Phase: применение к test/dev окружениям
Production Phase: постепенное внедрение в production

Exception Management

Управление исключениями для критичных случаев:

Project-level overrides: переопределение на уровне проекта
Temporary exemptions: временные исключения с expiration
Break-glass procedures: экстренные процедуры для critical incidents

# Исключение для specific проекта
constraint: "constraints/compute.vmExternalIpAccess"
listPolicy:
  allValues: "DENY"
  # Исключение для bastion host проекта
  inheritFromParent: false

Policy Monitoring and Compliance

Cloud Asset Inventory

Мониторинг соответствия политикам:

Policy violations detection: автоматическое обнаружение нарушений
Resource inventory: полная инвентаризация ресурсов организации
Change tracking: отслеживание изменений в ресурсах
Compliance reporting: отчеты о соответствии политикам

Security Command Center

Централизованная панель безопасности:

Policy insights: анализ эффективности политик
Violation alerts: уведомления о нарушениях политик
Risk assessment: оценка рисков безопасности
Remediation recommendations: рекомендации по устранению проблем

Advanced Policy Features

Conditional Policies

Условные политики с использованием CEL (Common Expression Language):

constraint: "constraints/compute.vmExternalIpAccess"
booleanPolicy:
  enforced: true
condition:
  expression: "resource.labels['environment'] != 'development'"
  title: "Allow external IP only in development"

Resource Hierarchy Inheritance

Наследование политик по иерархии:

Organization level: глобальные политики для всей компании
Folder level: политики для отделов или команд
Project level: специфичные политики проекта
Merge behavior: комбинирование политик с разных уровней

Delegated Administration

Делегированное управление политиками:

Policy Admin: может управлять политиками на своем уровне иерархии
Read-only access: просмотр политик без возможности изменения
Audit trail: полное логирование изменений политик

Практические сценарии применения

Multi-Environment Strategy

Стратегия для различных сред:

Development Environment:

Разрешены external IP для отладки
Relaxed image policies для экспериментов
Simplified IAM для быстрой разработки

Staging Environment:

Production-like policies для тестирования
Ограниченный набор разрешенных образов
Monitoring и logging как в production

Production Environment:

Максимально строгие security policies
Запрет SSH ключей и external IP
Mandatory encryption и audit logging
Restricted network access

Compliance Frameworks

Соответствие регулятивным требованиям:

PCI DSS Compliance:

Encryption at rest и in transit
Network segmentation через VPC
Access logging и monitoring
Regular vulnerability scanning

GDPR Compliance:

Data location restrictions
Encryption key management
Access audit trails
Data retention policies

SOX Compliance:

Segregation of duties
Change management controls
Financial data protection
Regular access reviews

Emergency Procedures

Аварийные процедуры и break-glass доступ:

Emergency access roles: временные elevated права
Policy suspension procedures: временное отключение политик
Incident response automation: автоматические действия при инцидентах
Audit trail preservation: сохранение логов экстренных действий

Мониторинг и отчетность

Policy Analytics

Аналитика эффективности политик:

Violation trends: тренды нарушений политик
Resource coverage: покрытие ресурсов политиками
Policy impact assessment: оценка влияния политик на операции
Optimization recommendations: рекомендации по оптимизации

Automated Remediation

Автоматическое исправление нарушений:

Cloud Functions triggers: автоматические действия при нарушениях
Resource tagging automation: автоматическое тегирование ресурсов
Compliance dashboard: real-time мониторинг соответствия
Integration with ITSM: интеграция с системами управления инцидентами

Google Cloud Data & Analytics

BigQuery - Хранилище данных

Основные концепции

BigQuery - это serverless, масштабируемое хранилище данных для аналитики. Основан на колоночном хранении и использует SQL для запросов.

Иерархия данных:

Project - верхний уровень, содержит datasets
Dataset - логическая группировка таблиц (аналог schema в СУБД)
Table - содержит данные в строках и столбцах

Типы таблиц

Native tables - обычные таблицы BigQuery
External tables - ссылки на данные в Cloud Storage, Drive, Bigtable
Views - виртуальные таблицы на основе SQL-запросов
Materialized views - предвычисленные результаты запросов

Партиционирование (Partitioning)

Разделение таблицы на сегменты для оптимизации запросов и снижения стоимости.

Типы партиционирования:

Time-unit column - по времени (день, час, месяц, год)
Ingestion time - по времени загрузки данных
Integer range - по диапазонам целых чисел

Преимущества:

Сканируются только нужные партиции
Снижение стоимости запросов
Улучшение производительности

-- Создание партиционированной таблицы по дате
CREATE TABLE dataset.orders_partitioned (
  order_id STRING,
  order_date DATE,
  amount NUMERIC
)
PARTITION BY order_date

Кластеризация (Clustering)

Сортировка данных внутри партиций по указанным столбцам (до 4 столбцов).

Когда использовать:

Частые фильтры по определенным столбцам
Высокая кардинальность данных
Большие таблицы (>1GB)

Прайсинг BigQuery

Модели оплаты:

On-demand pricing - оплата за объем обработанных данных
- $5 за TB обработанных данных
- Первый 1TB в месяц бесплатно
Flat-rate pricing - фиксированная стоимость за slots
- Slots - единицы вычислительной мощности
- 100 slots = $2000/месяц

Хранение данных:

Active storage - $0.02 за GB в месяц
Long-term storage - $0.01 за GB в месяц (таблицы не изменялись 90 дней)

Способы оптимизации затрат:

Партиционирование и кластеризация
Использование фильтров по партициям
Выбор только нужных столбцов
Избегание SELECT *

Dataflow - Потоковая и пакетная обработка

Основные концепции

Apache Beam - открытая модель программирования для обработки данных Dataflow - управляемый сервис Google для выполнения Beam pipeline

Типы обработки:

Batch processing - обработка больших объемов данных
Stream processing - обработка данных в реальном времени

Основные компоненты Pipeline

PCollection - набор данных (может быть ограниченным или неограниченным)
PTransform - операция обработки данных
Pipeline - направленный ациклический граф transformations
Runner - выполняет pipeline (Dataflow Runner, Direct Runner, etc.)

Основные трансформации:

ParDo - параллельная обработка элементов
GroupByKey - группировка по ключу
Combine - агрегация данных
Flatten - объединение нескольких PCollection
Windowing - разбиение потока на окна времени

Windowing (Оконные функции)

Разделение потоковых данных на конечные наборы для обработки.

Типы окон:

Fixed windows - неперекрывающиеся окна фиксированного размера
Sliding windows - перекрывающиеся окна
Session windows - окна с динамическим размером на основе активности

Dataproc - Управляемый Hadoop/Spark

Основные концепции

Dataproc - управляемый сервис для Apache Spark и Hadoop кластеров.

Компоненты:

Cluster - группа виртуальных машин
Master node - управляющий узел
Worker nodes - рабочие узлы
Preemptible instances - более дешевые, но могут быть остановлены

Преимущества:

Быстрое создание кластеров (90 секунд)
Автоматическое масштабирование
Интеграция с другими сервисами GCP
Preemptible instances для экономии

Spark на Dataproc

Apache Spark - движок для больших данных с возможностью in-memory обработки.

Компоненты Spark:

Spark Core - базовая функциональность
Spark SQL - работа со структурированными данными
Spark Streaming - потоковая обработка
MLlib - машинное обучение

Cloud Composer - Оркестрация процессов

Основные концепции

Apache Airflow - платформа для создания, планирования и мониторинга workflows Cloud Composer - управляемый Airflow в GCP

Ключевые компоненты:

DAG (Directed Acyclic Graph) - workflow, представленный как граф задач
Task - единица работы в DAG
Operator - определяет тип задачи (BashOperator, PythonOperator, etc.)
Scheduler - планировщик выполнения DAG

DAG структура

from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from datetime import datetime, timedelta

default_args = {
    'owner': 'data-team',
    'depends_on_past': False,
    'start_date': datetime(2024, 1, 1),
    'retries': 1,
    'retry_delay': timedelta(minutes=5)
}

dag = DAG('data_pipeline', 
          default_args=default_args,
          schedule_interval='@daily')

Операторы для GCP:

BigQueryOperator - выполнение SQL в BigQuery
DataflowOperator - запуск Dataflow jobs
DataprocOperator - управление Dataproc кластерами

Pub/Sub - Потоковая передача сообщений

Основные концепции

Cloud Pub/Sub - асинхронный сервис обмена сообщениями по модели publisher/subscriber.

Компоненты:

Topic - именованный канал для отправки сообщений
Subscription - именованный ресурс для получения сообщений
Publisher - отправляет сообщения в topic
Subscriber - получает сообщения из subscription

Типы доставки:

Pull - subscriber запрашивает сообщения
Push - Pub/Sub отправляет сообщения на HTTP endpoint

Гарантии доставки

At-least-once delivery - сообщение доставляется минимум один раз
Message ordering - порядок сообщений в рамках одного ключа
Message deduplication - устранение дублей по message ID

Архитектура потоков данных

Классическая схема: Pub/Sub → Dataflow → BigQuery

1. Pub/Sub (Ingestion)

Прием сообщений от различных источников
Буферизация и масштабирование нагрузки
Декаплинг производителей и потребителей

2. Dataflow (Processing)

Трансформация данных в реальном времени
Агрегация и обогащение данных
Обработка поздно пришедших данных (late data)

3. BigQuery (Storage & Analytics)

Хранение обработанных данных
Выполнение аналитических запросов
Интеграция с BI инструментами

Альтернативные схемы

Batch processing: Cloud Storage → Dataflow → BigQuery

Real-time analytics: Pub/Sub → Dataflow → Bigtable/Cloud SQL

ML Pipeline: BigQuery → AI Platform → Vertex AI

Мониторинг и логирование

Cloud Monitoring

Custom metrics - пользовательские метрики
SLI/SLO - индикаторы и цели уровня сервиса
Alerting policies - политики оповещений

Cloud Logging

Log sinks - экспорт логов в BigQuery, Cloud Storage
Log-based metrics - метрики на основе логов
Error Reporting - агрегация и анализ ошибок

Безопасность и управление доступом

IAM роли для Data & Analytics

BigQuery Data Viewer - чтение данных
BigQuery Data Editor - запись данных
BigQuery Job User - запуск запросов
Dataflow Admin - управление Dataflow jobs
Pub/Sub Editor - управление topics и subscriptions

Шифрование данных

Encryption at rest - шифрование хранимых данных
Encryption in transit - шифрование при передаче
Customer-managed encryption keys (CMEK) - собственные ключи шифрования

Оптимизация производительности

BigQuery оптимизация

Использование партиционирования и кластеризации
Денормализация для улучшения производительности
Материализованные представления для часто используемых запросов
Оптимизация JOIN операций

Dataflow оптимизация

Выбор подходящего типа машин
Настройка автоскейлинга
Оптимизация размера batch для операций
Использование side inputs для справочных данных

Интеграция с экосистемой GCP

Связь с другими сервисами

Cloud Storage - источник и приемник данных
Cloud SQL/Spanner - транзакционные базы данных
Vertex AI - машинное обучение
Looker/Data Studio - визуализация данных
Cloud Functions - событийная обработка

Google Cloud AI инструменты для Senior Java Backend разработчика

Основные категории AI сервисов Google Cloud

Vertex AI

Ключевая платформа для машинного обучения и AI в Google Cloud. Унифицированная среда для обучения, развертывания и управления моделями машинного обучения.

Основные возможности:

Автоматизированное машинное обучение (AutoML)
Пользовательские модели машинного обучения
Предобученные API для распространенных задач
MLOps и управление жизненным циклом моделей

// Пример создания прогноза через Vertex AI
PredictionServiceClient client = PredictionServiceClient.create();
PredictRequest request = PredictRequest.newBuilder()
    .setEndpoint(endpointName)
    .addAllInstances(instances)
    .build();
PredictResponse response = client.predict(request);

Предобученные AI API

Vision API

Анализ изображений с помощью машинного обучения. Распознает объекты, лица, текст, эмоции.

Ключевые функции:

Обнаружение объектов - идентификация предметов на изображении
Распознавание текста (OCR) - извлечение текста из изображений
Обнаружение лиц - поиск и анализ лиц людей
Классификация контента - определение неподходящего контента

ImageAnnotatorClient vision = ImageAnnotatorClient.create();
Image img = Image.newBuilder().setContent(imageBytes).build();
Feature feature = Feature.newBuilder().setType(Type.LABEL_DETECTION).build();
AnnotateImageRequest request = AnnotateImageRequest.newBuilder()
    .addFeatures(feature).setImage(img).build();

Natural Language API

Обработка естественного языка для анализа текста и извлечения смысла.

Основные возможности:

Анализ настроений - определение эмоциональной окраски текста
Извлечение сущностей - поиск людей, мест, организаций в тексте
Синтаксический анализ - разбор грамматической структуры
Классификация контента - категоризация текста по темам

LanguageServiceClient language = LanguageServiceClient.create();
Document doc = Document.newBuilder().setContent(text).setType(Type.PLAIN_TEXT).build();
AnalyzeSentimentRequest request = AnalyzeSentimentRequest.newBuilder()
    .setDocument(doc).build();
AnalyzeSentimentResponse response = language.analyzeSentiment(request);

Translation API

Машинный перевод между языками с использованием нейронных сетей Google.

Две версии:

Basic - быстрый перевод для простых задач
Advanced - более точный перевод с возможностью настройки

Translate translate = TranslateOptions.getDefaultInstance().getService();
Translation translation = translate.translate("Привет, мир!", 
    Translate.TranslateOption.targetLanguage("en"));

Speech-to-Text API

Преобразование аудио в текст с поддержкой множества языков и диалектов.

Особенности:

Потоковое распознавание речи в реальном времени
Пакетная обработка аудиофайлов
Автоматическое определение языка
Фильтрация нецензурной лексики

Text-to-Speech API

Синтез речи - преобразование текста в естественно звучащую речь.

Возможности:

Множество голосов и языков
Настройка скорости и тона речи
WaveNet голоса для более естественного звучания

AutoML - Автоматизированное машинное обучение

AutoML Vision

Создание пользовательских моделей для классификации изображений без глубоких знаний ML.

Применение:

Классификация продуктов в e-commerce
Контроль качества в производстве
Медицинская диагностика по изображениям

AutoML Natural Language

Пользовательские модели для обработки текста, обученные на ваших данных.

Задачи:

Классификация документов
Извлечение пользовательских сущностей
Анализ настроений для специфических доменов

AutoML Tables

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

Использование:

Прогнозирование продаж
Оценка кредитного риска
Рекомендательные системы

Специализированные AI решения

Document AI

Извлечение и структурирование данных из документов любого формата.

Возможности:

Обработка счетов, контрактов, форм
Извлечение ключевых полей
Классификация типов документов
Интеграция с системами документооборота

DocumentProcessorServiceClient client = DocumentProcessorServiceClient.create();
ProcessRequest request = ProcessRequest.newBuilder()
    .setName(processorName)
    .setRawDocument(rawDocument)
    .build();
ProcessResponse response = client.processDocument(request);

Contact Center AI (CCAI)

Улучшение работы контакт-центров с помощью ИИ.

Компоненты:

Agent Assist - подсказки операторам в реальном времени
Virtual Agents - чат-боты для автоматизации
Insights - анализ качества обслуживания

Recommendations AI

Система рекомендаций для e-commerce и контентных платформ.

Типы рекомендаций:

"Другие также покупали"
"Рекомендовано для вас"
"Часто покупают вместе"

AI Platform и MLOps

Vertex AI Pipelines

Оркестрация ML workflow для автоматизации процессов машинного обучения.

Ключевые концепции:

Pipeline - последовательность шагов ML процесса
Component - отдельный этап (предобработка, обучение, оценка)
Artifact - промежуточные результаты между этапами

Model Monitoring

Мониторинг производительности моделей в продуктивной среде.

Отслеживание:

Дрифт данных (изменение распределения входных данных)
Дрифт предсказаний (изменение результатов модели)
Производительность и задержки

Vertex AI Experiments

Управление экспериментами для отслеживания различных версий моделей.

Функциональность:

Версионирование моделей
Сравнение метрик между экспериментами
Воспроизводимость результатов

Интеграция с Java Backend

Аутентификация и авторизация

Service Account Keys - основной способ аутентификации для backend приложений.

// Настройка credentials из файла
GoogleCredentials credentials = GoogleCredentials
    .fromStream(new FileInputStream("path/to/service-account.json"))
    .createScoped(Lists.newArrayList("https://www.googleapis.com/auth/cloud-platform"));

Обработка ошибок

Правильная обработка исключений критична для стабильности системы.

try {
    // AI API вызов
} catch (ApiException e) {
    if (e.getStatusCode().getCode() == StatusCode.Code.RESOURCE_EXHAUSTED) {
        // Обработка превышения квот
    } else if (e.getStatusCode().getCode() == StatusCode.Code.INVALID_ARGUMENT) {
        // Обработка неверных параметров
    }
}

Асинхронная обработка

Long-running operations для задач, требующих много времени.

// Для длительных операций (например, обучение AutoML модели)
OperationFuture<TrainingPipeline, CreateTrainingPipelineOperationMetadata> future = 
    client.createTrainingPipelineAsync(parent, trainingPipeline);
TrainingPipeline response = future.get(); // Блокирующий вызов

Архитектурные паттерны

Batch vs Streaming

Выбор подхода зависит от требований к латентности:

Batch processing - для больших объемов данных, не критичных к времени
Streaming - для real-time обработки с низкой задержкой

Кэширование результатов

Оптимизация производительности и снижение затрат через кэширование.

@Cacheable(value = "predictions", key = "#inputData.hashCode()")
public PredictionResult getPrediction(InputData inputData) {
    return vertexAiService.predict(inputData);
}

Circuit Breaker Pattern

Защита от каскадных сбоев при недоступности AI сервисов.

@CircuitBreaker(name = "vertex-ai", fallbackMethod = "fallbackPrediction")
public PredictionResult callVertexAI(RequestData data) {
    return vertexAiClient.predict(data);
}

public PredictionResult fallbackPrediction(RequestData data, Exception ex) {
    return PredictionResult.defaultResult();
}

Мониторинг и логирование

Cloud Monitoring

Отслеживание метрик AI сервисов:

Количество запросов в секунду
Латентность ответов
Ошибки и их типы
Использование квот

Structured Logging

Логирование для анализа работы AI компонентов:

logger.info("AI prediction completed", 
    Map.of("model_id", modelId, 
           "latency_ms", latency,
           "confidence_score", confidence));

Квоты и лимиты

Rate Limits

Ограничения по запросам различаются между сервисами:

Vision API: 1800 запросов/минуту
Natural Language API: 5000 запросов/минуту
Translation API: 300 символов/секунду

Cost Optimization

Оптимизация затрат:

Использование батч-запросов где возможно
Кэширование частых запросов
Выбор подходящих по цене моделей
Мониторинг использования квот

Безопасность

Data Privacy

Защита данных:

Шифрование данных в покое и при передаче
Контроль доступа через IAM
Audit logs для отслеживания использования

Compliance

Соответствие требованиям:

GDPR compliance для европейских пользователей
Data residency (хранение данных в определенных регионах)
PCI DSS для финансовых данных

Google Cloud AI

Обзор AI сервисов Google Cloud

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

Ключевые преимущества GCP AI:

Предварительно обученные модели для быстрого старта
Возможность создания custom моделей
Автоматическое масштабирование и управление инфраструктурой
Интеграция с данными из BigQuery, Cloud Storage
Соответствие стандартам безопасности и compliance

Vertex AI - Унифицированная ML платформа

Основные концепции

Vertex AI — центральная платформа для всего ML жизненного цикла: от подготовки данных до развертывания и мониторинга моделей.

Ключевые компоненты:

Workbench — управляемые Jupyter notebooks для разработки
Training — обучение моделей с автоматическим hyperparameter tuning
Prediction — развертывание моделей для инференса
Pipelines — MLOps workflow для автоматизации процессов
Feature Store — централизованное хранение признаков
Model Registry — версионирование и управление моделями

AutoML возможности

AutoML позволяет создавать high-quality модели без глубокой экспертизы в ML:

Tables — табличные данные (классификация, регрессия)
Vision — распознавание изображений
Natural Language — обработка текста
Translation — машинный перевод
Video — анализ видео контента

Custom Training

Для более сложных задач Vertex AI поддерживает:

Pre-built containers — готовые окружения для популярных фреймворков
Custom containers — собственные Docker образы
Distributed training — обучение на нескольких GPU/TPU
Hyperparameter tuning — автоматический поиск оптимальных параметров

// Пример интеграции с Vertex AI для Java
import com.google.cloud.aiplatform.v1.*;

PredictionServiceClient client = PredictionServiceClient.create();
PredictRequest request = PredictRequest.newBuilder()
    .setEndpoint("projects/PROJECT_ID/locations/REGION/endpoints/ENDPOINT_ID")
    .addInstances(Value.newBuilder().setListValue(
        ListValue.newBuilder()
            .addValues(Value.newBuilder().setNumberValue(1.0))
            .addValues(Value.newBuilder().setStringValue("example"))
    ))
    .build();

PredictResponse response = client.predict(request);

Обработка языка и текста

Translation API

Cloud Translation — автоматический перевод текста между 100+ языками:

Basic Translation — быстрый перевод с автоопределением языка
Advanced Translation — custom модели и глоссарии
Document Translation — перевод документов с сохранением форматирования
Batch Translation — массовая обработка больших объемов

Практические применения:

Локализация приложений в реальном времени
Перевод пользовательского контента
Анализ многоязычных данных
Автоматическая модерация на разных языках

Natural Language AI

Natural Language API предоставляет готовые модели для анализа текста:

Sentiment Analysis — анализ тональности:

Определение положительной/отрицательной окраски
Оценка силы эмоций (magnitude)
Анализ по предложениям и документу в целом

Entity Recognition — извлечение сущностей:

Персоны, организации, места
Даты, числа, события
Custom entity types для специфических доменов

Syntax Analysis — грамматический анализ:

Части речи (POS tagging)
Зависимости между словами
Морфологический анализ

Content Classification — категоризация контента:

700+ предопределенных категорий
Confidence scores для каждой категории
Иерархическая структура классов

// Анализ тональности текста
import com.google.cloud.language.v1.*;

try (LanguageServiceClient language = LanguageServiceClient.create()) {
    Document doc = Document.newBuilder()
        .setContent("Этот продукт превосходен!")
        .setType(Document.Type.PLAIN_TEXT)
        .build();
    
    AnalyzeSentimentResponse response = language.analyzeSentiment(
        AnalyzeSentimentRequest.newBuilder()
            .setDocument(doc)
            .build());
    
    Sentiment sentiment = response.getDocumentSentiment();
    System.out.printf("Score: %.3f, Magnitude: %.3f%n",
        sentiment.getScore(), sentiment.getMagnitude());
}

Обработка изображений и видео

Vertex AI Vision

Computer Vision решения для анализа визуального контента:

Object Detection — обнаружение объектов:

Bounding boxes с координатами
Confidence scores для каждого объекта
Support для 600+ классов объектов
Custom object detection модели

Image Classification — классификация изображений:

Предобученные модели для общих категорий
Custom classification для специфических задач
Multi-label classification
Transfer learning для быстрого обучения

OCR (Optical Character Recognition):

Извлечение текста из изображений
Поддержка 50+ языков
Handwriting recognition
Document structure analysis

Face Detection — анализ лиц:

Detection landmarks (глаза, нос, рот)
Emotion detection
Age и gender estimation
Face matching и clustering

Video Intelligence API

Анализ видео контента для автоматической обработки:

Shot Change Detection — детекция смены кадров Label Detection — автоматическая разметка контента Explicit Content Detection — модерация неподходящего контента Speech Transcription — преобразование речи в текст Object Tracking — отслеживание объектов во времени

Речевые технологии

Speech-to-Text API

Преобразование аудио в текст с продвинутыми возможностями:

Real-time Streaming — потоковое распознавание:

Низкая латентность для интерактивных приложений
Interim results для промежуточных результатов
Voice activity detection
Automatic punctuation

Batch Processing — пакетная обработка:

Длинные аудиофайлы (до 8 часов)
Multiple speaker diarization
Word-level timestamps и confidence
Custom vocabulary для специфических терминов

Language Support — поддержка языков:

125+ языков и диалектов
Automatic language detection
Code-switching для смешанных языков
Regional variants

// Пример распознавания речи
import com.google.cloud.speech.v1.*;

try (SpeechClient speechClient = SpeechClient.create()) {
    RecognitionConfig config = RecognitionConfig.newBuilder()
        .setEncoding(RecognitionConfig.AudioEncoding.LINEAR16)
        .setSampleRateHertz(16000)
        .setLanguageCode("ru-RU")
        .setEnableAutomaticPunctuation(true)
        .build();
    
    RecognitionAudio audio = RecognitionAudio.newBuilder()
        .setContent(ByteString.readFrom(audioInputStream))
        .build();
    
    RecognizeResponse response = speechClient.recognize(config, audio);
    
    for (SpeechRecognitionResult result : response.getResultsList()) {
        System.out.println("Transcript: " + result.getAlternatives(0).getTranscript());
        System.out.println("Confidence: " + result.getAlternatives(0).getConfidence());
    }
}

Text-to-Speech API

Синтез речи для создания естественно звучащего аудио:

Voice Selection — выбор голосов:

380+ голосов на 50+ языках
Standard и WaveNet voices
Neural2 voices для максимального качества
Custom voice cloning

SSML Support — разметка для контроля произношения:

Паузы и ударения
Скорость и тембр речи
Pronunciation hints
Audio effects

Document AI - Интеллектуальная обработка документов

Возможности Document AI

Document AI — платформа для извлечения структурированных данных из неструктурированных документов:

Form Parser — обработка форм:

Извлечение key-value пар
Table extraction с сохранением структуры
Checkbox и signature detection
Multi-page document support

Specialized Processors — предобученные парсеры:

Invoice Parser — счета и инвойсы
Receipt Parser — чеки и квитанции
ID Parser — документы удостоверяющие личность
Contract Parser — договоры и контракты
Tax Forms — налоговые документы

Custom Document Extractors — создание custom парсеров:

Обучение на собственных документах
Active learning для улучшения качества
Human-in-the-loop для сложных случаев
Workflow integration

Document AI Workbench

Инструмент для создания и управления custom processors:

Visual annotation interface
Dataset management
Model training и evaluation
Version control для моделей
A/B testing для сравнения версий

Enterprise AI решения

Contact Center AI (CCAI)

AI-powered платформа для контакт-центров:

Virtual Agents — чат-боты и голосовые ассистенты:

Natural language understanding
Multi-turn conversations
Integration с бизнес-системами
Handoff to human agents

Agent Assist — помощь операторам:

Real-time suggestions
Knowledge base search
Sentiment analysis клиентов
Conversation summarization

Insights — аналитика взаимодействий:

Call transcription и analysis
Trend detection
Performance metrics
Compliance monitoring

Discovery Engine

Поисковые решения для enterprise приложений:

Search Applications — корпоративный поиск:

Semantic search с ML
Multi-modal search (текст, изображения)
Personalization на основе поведения
Real-time indexing

Recommendation Engines — рекомендательные системы:

Collaborative filtering
Content-based recommendations
Hybrid approaches
Cold start problem решения

Talent Solution

ML-powered решения для HR и рекрутинга:

Job Search — интеллектуальный поиск вакансий:

Semantic matching навыков
Location и commute preferences
Salary range optimization
Career progression suggestions

Candidate Matching — подбор кандидатов:

Resume parsing и analysis
Skill gap identification
Diversity и inclusion metrics
Automated screening

Практические аспекты для Senior разработчика

Архитектурные паттерны

Event-driven ML Pipeline:

Cloud Pub/Sub для триггеринга обработки
Cloud Functions для lightweight preprocessing
Vertex AI Pipelines для комплексных workflow
BigQuery для аналитики результатов

Microservices with AI:

Отдельные сервисы для каждой AI функции
API Gateway для управления доступом
Circuit breaker pattern для устойчивости
Caching для оптимизации performance

Data Pipeline Architecture:

Streaming data с Dataflow
Batch processing с Dataproc
Feature engineering в Vertex AI
Model serving через REST/gRPC endpoints

Security и Compliance

Data Protection:

Encryption at rest и in transit
VPC Service Controls для изоляции
Customer-managed encryption keys (CMEK)
Data Loss Prevention (DLP) integration

Model Security:

Binary Authorization для container images
Workload Identity для GKE integration
Service accounts с минимальными правами
Audit logging для всех ML operations

Privacy Considerations:

Differential privacy techniques
Federated learning для distributed data
Data anonymization strategies
GDPR compliance requirements

Performance Optimization

Model Serving Optimization:

Model quantization для reduced latency
Batch prediction для high throughput
Auto-scaling based на request volume
Edge deployment с AI Edge Portal

Cost Management:

Preemptible instances для training
Committed use discounts
Model compression techniques
Efficient data storage strategies

Monitoring и MLOps

Model Monitoring:

Data drift detection
Model performance degradation
Feature importance tracking
Prediction confidence analysis

MLOps Best Practices:

Version control для datasets и models
Automated testing для ML pipelines
Continuous integration/deployment
A/B testing framework

Integration Patterns

Spring Boot Integration:

@Service
public class AIService {
    private final PredictionServiceClient vertexClient;
    private final LanguageServiceClient languageClient;
    
    @Value("${gcp.ai.vertex.endpoint}")
    private String vertexEndpoint;
    
    public PredictionResult predict(InputData data) {
        // Vertex AI prediction logic
        return vertexClient.predict(buildRequest(data));
    }
    
    public SentimentResult analyzeSentiment(String text) {
        // Natural Language API integration
        return languageClient.analyzeSentiment(buildDocument(text));
    }
}

Reactive Streams для Real-time Processing:

@Component
public class StreamingAIProcessor {
    
    public Flux<ProcessedResult> processStream(Flux<InputData> inputStream) {
        return inputStream
            .buffer(Duration.ofSeconds(1)) // Batch for efficiency
            .flatMap(this::batchPredict)
            .onErrorContinue((error, item) -> 
                log.error("Processing error", error));
    }
}

Error Handling и Resilience

Retry Strategies:

Exponential backoff для transient errors
Circuit breaker для service protection
Fallback mechanisms для degraded service
Dead letter queues для failed requests

Quality Assurance:

Input validation и sanitization
Output confidence thresholds
Human review для low-confidence results
Automated quality metrics

Выбор подходящего AI сервиса

Критерии выбора

Требования к latency:

Real-time: предобученные API
Near real-time: Vertex AI endpoints
Batch: BigQuery ML или Vertex AI training

Объем данных:

Малый объем: готовые API
Средний объем: AutoML
Большой объем: Custom training

Специфичность домена:

Общие задачи: предобученные модели
Специфичные задачи: custom models
Hybrid подход: transfer learning

Budget Considerations:

Proof of concept: бесплатные квоты
Production: committed use discounts
High volume: custom pricing

Типичные use cases для Backend разработчика

Content Moderation:

Автоматическая проверка пользовательского контента
Классификация по категориям
Sentiment analysis для отзывов

Search Enhancement:

Semantic search в knowledge base
Auto-complete с ML suggestions
Personalized content recommendations

Data Processing Automation:

Document parsing для onboarding
Invoice processing automation
Customer support ticket routing

Analytics и Insights:

Customer behavior analysis
Market sentiment tracking
Anomaly detection в business metrics

Google Cloud Platform - Шаблоны решений

Статический сайт

Архитектура

Классическое решение для фронтенда: статические файлы в хранилище + CDN для ускорения + балансировщик для SSL.

Компоненты:

Cloud Storage (GCS) - объектное хранилище для статических файлов (HTML, CSS, JS, изображения)
Cloud CDN - сеть доставки контента для кэширования на edge-серверах
Cloud Load Balancer - HTTPS Load Balancer для терминации SSL и маршрутизации
Cloud DNS - управляемый DNS для доменных имен
Managed SSL Certificate - автоматические SSL сертификаты от Google

Настройка

1. Создание bucket в Cloud Storage:

gsutil mb gs://your-website-bucket
gsutil web set -m index.html -e 404.html gs://your-website-bucket

2. Загрузка файлов:

gsutil -m cp -r ./dist/* gs://your-website-bucket
gsutil -m acl ch -r -u AllUsers:R gs://your-website-bucket

3. Настройка Load Balancer через Console:

Backend: Cloud Storage bucket
Frontend: HTTPS с managed certificate
Привязка домена через Cloud DNS

Преимущества

Масштабируемость: автоматическое масштабирование CDN
Производительность: глобальный кэш контента
Безопасность: автоматические SSL сертификаты
Стоимость: платишь только за трафик и хранение

Контейнерный бэкенд

Архитектура

Serverless контейнеры для Java приложений с базой данных и кэшем. Идеально для REST API и микросервисов.

Компоненты:

Cloud Run - serverless контейнерная платформа (pay-per-request)
VPC Connector - приватное подключение к VPC сети
Cloud SQL - управляемая PostgreSQL/MySQL база данных
Memorystore (Redis) - управляемый Redis для кэширования
Cloud Load Balancer - HTTPS балансировщик с SSL терминацией
Cloud Armor - WAF (Web Application Firewall) для защиты от атак
Identity-Aware Proxy (IAP) - аутентификация на уровне Google Identity

Настройка Cloud Run

Dockerfile для Spring Boot:

FROM openjdk:17-jre-slim
COPY target/app.jar app.jar
EXPOSE 8080
CMD ["java", "-jar", "app.jar"]

Деплой в Cloud Run:

gcloud run deploy my-service \
  --image gcr.io/PROJECT/my-app \
  --region europe-west1 \
  --vpc-connector my-connector \
  --set-env-vars "DB_HOST=10.1.1.3"

Конфигурация базы данных

Cloud SQL (PostgreSQL):

Приватный IP в VPC
Автоматические бэкапы
Высокая доступность (HA)
Connection pooling через PgBouncer

Memorystore Redis:

Приватная сеть VPC
Автоматическое масштабирование памяти
Репликация для отказоустойчивости

Безопасность

Cloud Armor правила:

Rate limiting (например, 100 req/min per IP)
Geo-блокировка стран
OWASP Top 10 защита
Custom rules на основе заголовков

IAP настройка:

OAuth 2.0 с Google Workspace
Роли IAM для доступа
Интеграция с корпоративным SSO

Преимущества

Zero ops: не нужно управлять серверами
Автомасштабирование: от 0 до тысяч инстансов
Экономия: платишь только за время выполнения запросов
Интеграция: нативная интеграция с GCP сервисами

Kubernetes (GKE)

Архитектура

Полноценная платформа для сложных приложений с микросервисной архитектурой.

Компоненты:

GKE Autopilot - полностью управляемый Kubernetes без управления нодами
Google Cloud Load Balancer (GCLB) - Ingress контроллер для внешнего трафика
Artifact Registry - приватный Docker registry для образов
Cloud Deploy - GitOps пайплайн для автоматического деплоя
Config Connector - управление GCP ресурсами через Kubernetes YAML

Создание кластера

GKE Autopilot кластер:

gcloud container clusters create-auto my-cluster \
  --region=europe-west1 \
  --release-channel=stable

Настройка Ingress

Ingress для Java приложения:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "my-static-ip"
    networking.gke.io/managed-certificates: "my-ssl-cert"
spec:
  rules:

  - host: api.example.com
    http:
      paths:

      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-java-service
            port:
              number: 8080

Artifact Registry

Настройка Docker registry:

gcloud artifacts repositories create my-repo \
  --repository-format=docker \
  --location=europe-west1

# Push образа
docker tag my-app europe-west1-docker.pkg.dev/PROJECT/my-repo/my-app:v1.0
docker push europe-west1-docker.pkg.dev/PROJECT/my-repo/my-app:v1.0

GitOps с Cloud Deploy

Конфигурация пайплайна:

apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-pipeline
spec:
  stages:

  - targetId: staging
    profiles: ["staging"]
  - targetId: production 
    profiles: ["prod"]

Автоматический деплой при коммите:

Trigger в Cloud Build на push в main
Сборка образа и push в Artifact Registry
Cloud Deploy автоматически деплоит в staging
Manual approval для production

Мониторинг и логирование

Google Cloud Operations Suite:

Cloud Monitoring - метрики приложений и инфраструктуры
Cloud Logging - централизованные логи всех подов
Cloud Trace - distributed tracing для микросервисов
Cloud Profiler - профилирование производительности Java приложений

Service Mesh (Istio)

Установка Istio в GKE:

gcloud container clusters update my-cluster \
  --update-addons=Istio=ENABLED

Возможности Istio:

Traffic management - routing, load balancing, circuit breaker
Security - mTLS между сервисами, authorization policies
Observability - автоматические метрики, трейсинг, логи
Policy enforcement - rate limiting, quota management

Преимущества GKE

Полное управление: Google управляет control plane
Безопасность: автоматические обновления, vulnerability scanning
Интеграция: нативная работа с GCP сервисами
Масштабируемость: автоматическое масштабирование кластера и подов

Выбор архитектуры

Статический сайт

Используй когда: SPA фронтенд, лендинги, документация Не используй когда: нужна серверная логика, динамический контент

Cloud Run

Используй когда: REST API, микросервисы, периодические задачи Не используй когда: долгоживущие процессы, сложная сетевая топология

GKE

Используй когда: сложные приложения, микросервисы, legacy системы Не используй когда: простые приложения, ограниченные DevOps ресурсы

Общие принципы

Безопасность

Least privilege - минимальные IAM права
Private networking - VPC для изоляции ресурсов
Encryption - в покое и в передаче
Audit logging - логирование всех действий

Мониторинг

SLI/SLO - определение метрик надёжности
Alerting - уведомления при проблемах
Dashboards - визуализация метрик
Cost monitoring - контроль расходов

CI/CD

Infrastructure as Code - Terraform для инфраструктуры
GitOps - декларативное управление через Git
Automated testing - unit, integration, e2e тесты
Blue-green deployments - безопасные релизы

Google Cloud gcloud CLI — мини-шпаргалка

Аутентификация и начальная настройка

Application Default Credentials (ADC)

ADC — это механизм автоматического поиска учетных данных для приложений Google Cloud. Клиентские библиотеки автоматически используют эти credentials без явного указания ключей.

# Настройка ADC для локальной разработки
gcloud auth application-default login

# Просмотр текущих ADC
gcloud auth application-default print-access-token

# Отзыв ADC
gcloud auth application-default revoke

Когда использовать: Для локальной разработки Java-приложений, которые будут использовать Google Cloud SDK/библиотеки.

Основная аутентификация

# Вход в аккаунт
gcloud auth login

# Просмотр активного аккаунта
gcloud auth list

# Переключение между аккаунтами
gcloud config set account ACCOUNT

Конфигурация проекта и регионов

Управление конфигурациями

Configuration — это набор настроек gcloud CLI (проект, регион, зона). Позволяет быстро переключаться между разными окружениями.

# Создание новой конфигурации
gcloud config configurations create НАЗВАНИЕ

# Переключение между конфигурациями
gcloud config configurations activate НАЗВАНИЕ

# Список всех конфигураций
gcloud config configurations list

Настройка проекта и регионов

# Установка проекта по умолчанию
gcloud config set project PROJECT_ID

# Установка региона по умолчанию
gcloud config set compute/region europe-west1

# Установка зоны по умолчанию
gcloud config set compute/zone europe-west1-b

# Просмотр всех настроек
gcloud config list

Регион vs Зона: Регион — это географическая область (например, europe-west1). Зона — это конкретный дата-центр внутри региона (europe-west1-a).

Cloud Run — контейнерный сервис

Cloud Run — это fully managed платформа для запуска контейнеризованных приложений. Автоматически масштабируется от 0 до N инстансов, оплата только за использование.

Деплой приложений

# Деплой из исходного кода (автоматическая сборка)
gcloud run deploy SERVICE_NAME \
  --source . \
  --region europe-west1

# Деплой готового Docker-образа
gcloud run deploy SERVICE_NAME \
  --image gcr.io/PROJECT/IMAGE:TAG \
  --region europe-west1 \
  --platform managed

Управление сервисами

# Список сервисов
gcloud run services list

# Описание сервиса
gcloud run services describe SERVICE_NAME --region=REGION

# Удаление сервиса
gcloud run services delete SERVICE_NAME --region=REGION

Настройка ресурсов и переменных

# Установка переменных окружения
gcloud run services update SERVICE_NAME \
  --set-env-vars "DB_HOST=localhost,API_KEY=secret"

# Настройка ресурсов
gcloud run services update SERVICE_NAME \
  --memory 1Gi \
  --cpu 2 \
  --max-instances 10

Memory — память на один инстанс (128Mi-32Gi). CPU — количество виртуальных CPU (0.08-8). Max-instances — максимальное количество одновременных инстансов.

IAM — управление доступом

IAM (Identity and Access Management) — система управления доступом в Google Cloud. Основана на принципе предоставления минимально необходимых прав.

Основные роли и права

# Добавление роли пользователю
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:email@domain.com" \
  --role="roles/viewer"

# Добавление роли сервисному аккаунту
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:SA_NAME@PROJECT.iam.gserviceaccount.com" \
  --role="roles/storage.admin"

# Просмотр IAM политик проекта
gcloud projects get-iam-policy PROJECT_ID

Сервисные аккаунты

Service Account — это специальный тип аккаунта, используемый приложениями и виртуальными машинами для взаимодействия с Google Cloud API.

# Создание сервисного аккаунта
gcloud iam service-accounts create SA_NAME \
  --display-name="Описание аккаунта"

# Создание и скачивание ключа
gcloud iam service-accounts keys create key.json \
  --iam-account=SA_NAME@PROJECT.iam.gserviceaccount.com

# Список сервисных аккаунтов
gcloud iam service-accounts list

Часто используемые роли для Java Backend

roles/viewer — просмотр ресурсов
roles/editor — редактирование ресурсов
roles/storage.admin — полный доступ к Cloud Storage
roles/cloudsql.client — подключение к Cloud SQL
roles/secretmanager.secretAccessor — доступ к Secret Manager

Логи и мониторинг

Cloud Logging — централизованная система сбора и анализа логов. Cloud Monitoring — система мониторинга метрик и создания алертов.

Просмотр логов

# Логи Cloud Run сервиса
gcloud logs read "resource.type=cloud_run_revision AND resource.labels.service_name=SERVICE_NAME" \
  --limit=50 \
  --format="table(timestamp,textPayload)"

# Логи за определенный период
gcloud logs read "timestamp>='2024-01-01T00:00:00Z'" \
  --limit=100

# Следование за логами в реальном времени
gcloud logs tail "resource.type=cloud_run_revision"

Метрики и мониторинг

# Список доступных метрик
gcloud logging metrics list

# Создание кастомной метрики
gcloud logging metrics create METRIC_NAME \
  --description="Описание метрики" \
  --log-filter="severity>=ERROR"

Log Filter — язык запросов для фильтрации логов по различным критериям (время, уровень, ресурс, содержимое).

Полезные команды для повседневной работы

Информация о проекте и ресурсах

# Информация о текущем проекте
gcloud config get-value project

# Список всех проектов
gcloud projects list

# Квоты и лимиты проекта
gcloud compute project-info describe

# Активные сервисы API
gcloud services list --enabled

Работа с Container Registry/Artifact Registry

# Настройка Docker для работы с GCR
gcloud auth configure-docker

# Настройка для Artifact Registry
gcloud auth configure-docker europe-west1-docker.pkg.dev

# Список образов в registry
gcloud container images list --repository=gcr.io/PROJECT_ID

Container Registry vs Artifact Registry: Container Registry — устаревший сервис для Docker-образов. Artifact Registry — новый универсальный репозиторий для всех типов артефактов.

Управление API и сервисами

# Включение API
gcloud services enable run.googleapis.com

# Отключение API
gcloud services disable SERVICE_NAME

# Список доступных API
gcloud services list --available

Советы для Senior Java Backend разработчика

Безопасность и best practices

Никогда не коммитьте service account ключи в Git
Используйте IAM роли с минимальными правами вместо широких ролей типа Editor
Настройте ADC локально для разработки вместо использования JSON ключей
Используйте разные проекты для dev/staging/production окружений

Интеграция с Java приложениями

Spring Cloud GCP — официальная интеграция Spring Boot с Google Cloud
Google Cloud Libraries for Java — нативные клиентские библиотеки
Micrometer — для экспорта метрик в Cloud Monitoring
Logback/SLF4J — для структурированного логирования в Cloud Logging

Автоматизация и CI/CD

# Создание deployment pipeline
gcloud builds submit --config=cloudbuild.yaml

# Автоматический деплой при push в репозиторий
gcloud builds triggers create github \
  --repo-name=REPO_NAME \
  --branch-pattern=main \
  --build-config=cloudbuild.yaml

Cloud Build — это managed CI/CD сервис Google Cloud, который может автоматически собирать и деплоить приложения при изменениях в Git репозитории.

Google Cloud Troubleshooting чек-лист

IAM (Identity and Access Management)

Основы IAM

IAM — система управления доступом в GCP, основанная на модели "кто имеет какой доступ к каким ресурсам".

Основные компоненты:

Principal (кто) — пользователь, сервисный аккаунт, группа
Role (что можно делать) — набор разрешений
Resource (к чему) — проект, bucket, VM и т.д.

Диагностика проблем доступа

1. Проверка текущих разрешений:

# Проверить IAM policy для проекта
gcloud projects get-iam-policy PROJECT_ID

# Проверить разрешения конкретного пользователя
gcloud projects test-iam-permissions PROJECT_ID \
  --member="user:example@company.com" \
  --permissions="compute.instances.list,storage.buckets.create"

2. Policy Troubleshooter — инструмент GCP для диагностики проблем доступа:

Показывает, почему доступ разрешен или запрещен
Анализирует все уровни политик (организация → папка → проект → ресурс)
Учитывает условные политики и deny rules

3. Частые проблемы:

Наследование ролей — роли наследуются от родительских ресурсов
Кэширование разрешений — изменения могут применяться до 7 минут
Сервисные аккаунты — проверить, что у SA есть нужные роли
API включены — многие разрешения требуют включенных API

Deny Policies

Deny policies — явный запрет доступа, имеет приоритет над allow.

Проверка deny правил:

# Список deny policies
gcloud iam deny-policies list --resource=PROJECT_ID

# Детали конкретной политики
gcloud iam deny-policies describe POLICY_ID \
  --resource=PROJECT_ID

VPC (Virtual Private Cloud)

Маршрутизация (Routes)

Типы маршрутов:

System routes — автоматические (подсети, default gateway)
Custom routes — созданные пользователем
Peering routes — от VPC peering или Cloud Interconnect

Диагностика маршрутизации:

# Список всех маршрутов
gcloud compute routes list

# Эффективные маршруты для VM
gcloud compute instances describe INSTANCE_NAME \
  --zone=ZONE --format="get(networkInterfaces[0].accessConfigs[0].natIP)"

# Network connectivity тест
gcloud network-management connectivity-tests create TEST_NAME \
  --source-instance=SOURCE_VM \
  --destination-ip-address=DEST_IP

Приоритет маршрутов:

Более специфичные маршруты (меньшая маска подсети)
Меньшее значение priority (0-65535, где 0 — наивысший)
System routes всегда имеют priority 1000

Firewall Rules

Направления трафика:

Ingress — входящий трафик (по умолчанию deny all)
Egress — исходящий трафик (по умолчанию allow all)

Компоненты правила:

Target — к чему применяется (tags, service accounts, все инстансы)
Source/Destination — откуда/куда (IP ranges, tags, service accounts)
Protocol & Ports — TCP/UDP/ICMP и порты
Action — Allow/Deny
Priority — 0-65535 (меньше = выше приоритет)

Диагностика Firewall:

# Список правил
gcloud compute firewall-rules list

# Firewall Insights — анализ неиспользуемых правил
gcloud compute firewall-rules list --format="table(name,direction,priority,sourceRanges.list():label=SRC_RANGES)"

# Логи Firewall (включить в VPC Flow Logs)
gcloud compute networks subnets update SUBNET_NAME \
  --enable-flow-logs --region=REGION

VPC Flow Logs — детальные логи сетевого трафика для диагностики:

Источник/назначение IP и порты
Количество пакетов и байт
Accept/Drop решения firewall

DNS

Cloud DNS

Cloud DNS — управляемый DNS сервис Google Cloud.

Типы зон:

Public zones — публичные DNS записи
Private zones — внутренние DNS для VPC
Forwarding zones — перенаправление запросов на другие DNS
Peering zones — общий доступ к DNS между VPC

Диагностика DNS:

# Проверка записей в зоне
gcloud dns record-sets list --zone=ZONE_NAME

# Тест разрешения DNS
nslookup domain.com
dig @8.8.8.8 domain.com

# DNS политики для VPC
gcloud dns policies list

Частые проблемы:

Split-horizon DNS — разные ответы для internal/external запросов
DNS кэширование — TTL влияет на скорость обновления
VPC DNS настройки — private.googleapis.com для Private Google Access

Metadata Server

Metadata server (169.254.169.254) — источник информации для VM:

Service account tokens
Instance metadata
SSH ключи

SSL/TLS

Google-managed certificates

Google-managed SSL — автоматическое управление сертификатами:

Автоматическое обновление
Поддержка только Domain Validation
Интеграция с Load Balancer

Self-managed certificates

Self-managed — загрузка собственных сертификатов:

Больше контроля
Поддержка wildcard и EV сертификатов
Ручное обновление

Диагностика SSL:

# Список сертификатов
gcloud compute ssl-certificates list

# Проверка статуса managed сертификата
gcloud compute ssl-certificates describe CERT_NAME --global

# Тест SSL соединения
openssl s_client -connect domain.com:443 -servername domain.com

Quotas (Квоты)

Типы квот

Regional quotas — ограничения по регионам (VM, диски) Global quotas — глобальные ограничения (projects, networks) Per-project quotas — ограничения на проект

Мониторинг квот:

# Просмотр всех квот
gcloud compute project-info describe --project=PROJECT_ID

# Квоты по регионам
gcloud compute regions describe REGION_NAME

# Использование квот через API
gcloud alpha monitoring metrics list --filter="metric.type:compute.googleapis.com"

Увеличение квот:

IAM Console → Quotas
Выбрать нужную квоту
Edit quotas → Request increase
Обоснование необходимости увеличения

Load Balancer Логи

HTTP(S) Load Balancer

Cloud Load Balancing — глобальный балансировщик нагрузки Google.

Компоненты:

Frontend — IP адрес и порт для приема трафика
Backend Service — группа backend'ов с настройками health check
URL Map — правила маршрутизации по path/host
SSL Policy — настройки TLS

Диагностика через логи:

# Включение логов для backend service
gcloud compute backend-services update BACKEND_SERVICE_NAME \
  --enable-logging --logging-sample-rate=1.0 --global

# Просмотр логов в Cloud Logging
gcloud logging read 'resource.type="http_load_balancer"' \
  --limit=50 --format=json

Ключевые поля в логах:

httpRequest.status — HTTP статус код
httpRequest.responseSize — размер ответа
httpRequest.latency — задержка запроса
backendServiceName — какой backend обработал запрос

Network Load Balancer

Regional TCP/UDP Load Balancer — L4 балансировщик.

Особенности:

Работает на уровне TCP/UDP
Preserve client IP
Regional (не global)
Высокая производительность

Serverless Логи

Cloud Functions

Cloud Functions — serverless платформа для выполнения кода.

Диагностика Functions:

# Логи функции
gcloud functions logs read FUNCTION_NAME --region=REGION

# Метрики функции
gcloud functions describe FUNCTION_NAME --region=REGION

# Тестирование функции
gcloud functions call FUNCTION_NAME --data='{"key":"value"}'

Частые проблемы:

Cold start — задержка при первом запуске
Memory limits — нехватка памяти (128MB-8GB)
Timeout — превышение лимита времени выполнения
Concurrency — ограничение параллельных выполнений

Cloud Run

Cloud Run — serverless контейнерная платформа.

Диагностика Cloud Run:

# Логи сервиса
gcloud run services logs read SERVICE_NAME --region=REGION

# Статус и конфигурация
gcloud run services describe SERVICE_NAME --region=REGION

# Ревизии сервиса
gcloud run revisions list --service=SERVICE_NAME --region=REGION

Автоскейлинг факторы:

Request per second — запросы в секунду
CPU utilization — использование CPU
Memory usage — потребление памяти
Custom metrics — пользовательские метрики

Здоровье Backend'ов

Health Checks

Health Check — механизм проверки доступности backend'ов.

Типы проверок:

HTTP/HTTPS — проверка HTTP endpoint'а
TCP — проверка TCP соединения
SSL — проверка SSL handshake
HTTP/2 — проверка HTTP/2 соединения

Параметры Health Check:

Check interval — интервал проверок (1-300 сек)
Timeout — таймаут проверки (1-300 сек)
Healthy threshold — количество успешных проверок для "healthy"
Unhealthy threshold — количество неудачных для "unhealthy"

Диагностика:

# Список health checks
gcloud compute health-checks list

# Статус backend'ов
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --global

# Детали health check
gcloud compute health-checks describe HEALTH_CHECK_NAME

Backend Service статусы

HEALTHY — backend отвечает на health checks UNHEALTHY — backend не проходит health checks DRAINING — backend готовится к остановке TIMEOUT — health check не получает ответ в срок

Proxy и Egress

Cloud NAT

Cloud NAT — Network Address Translation для исходящего трафика.

Назначение:

Позволяет VM без внешних IP подключаться к интернету
Статические IP для исходящих соединений
Логирование исходящих соединений

Диагностика Cloud NAT:

# Статус NAT gateway
gcloud compute routers nats describe NAT_NAME \
  --router=ROUTER_NAME --region=REGION

# NAT логи
gcloud logging read 'resource.type="nat_gateway"' --limit=50

Private Google Access

Private Google Access — доступ к Google API без внешних IP.

Настройка:

Включить на уровне subnet
Настроить DNS для private.googleapis.com
Firewall правила для 199.36.153.8/30

Проверка:

# Статус Private Google Access для subnet
gcloud compute networks subnets describe SUBNET_NAME \
  --region=REGION --format="get(privateIpGoogleAccess)"

# Тест доступа к Google API
curl -H "Metadata-Flavor: Google" \
  http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Egress трафик

Исходящий трафик может идти через:

Internet Gateway — прямой выход в интернет
Cloud NAT — через NAT gateway
VPN/Interconnect — через on-premises
Proxy servers — через proxy

Мониторинг egress:

VPC Flow Logs
Firewall logs
Cloud NAT logs
Network topology в консоли GCP

Инструменты диагностики

Cloud Console Network Intelligence

Network Intelligence Center — централизованная диагностика сети:

Network Topology — визуализация сетевой архитектуры
Connectivity Tests — тестирование соединений между ресурсами
Performance Dashboard — мониторинг производительности
Firewall Insights — анализ правил firewall

Мониторинг и алерты

Cloud Monitoring — система мониторинга GCP:

Метрики ресурсов
Custom metrics
Dashboards
Alerting policies

Cloud Logging — централизованное логирование:

Логи всех сервисов GCP
Фильтрация и поиск
Export в BigQuery или Cloud Storage
Real-time streaming

Команды для быстрой диагностики

# Проверка сетевого стека VM
gcloud compute instances get-serial-port-output INSTANCE_NAME --zone=ZONE

# Connectivity тест между VM
gcloud network-management connectivity-tests create test-vm-to-vm \
  --source-instance=projects/PROJECT/zones/ZONE/instances/VM1 \
  --destination-instance=projects/PROJECT/zones/ZONE/instances/VM2

# Трассировка маршрута
gcloud compute instances describe INSTANCE_NAME --zone=ZONE \
  --format="get(networkInterfaces[].network)"

Часто путаемые термины

Load Balancer (Балансировщики нагрузки)

Global HTTP(S) Load Balancer

Что это: Глобальный балансировщик уровня 7 (HTTP/HTTPS), работает на Google Front End (GFE)

Единственный IP-адрес для всего мира
SSL termination на edge-серверах Google
URL-based routing (маршрутизация по путям)
Интеграция с Cloud CDN
Automatic scaling и DDoS protection

Когда использовать: Веб-приложения с пользователями по всему миру

Regional Network Load Balancer

Что это: Региональный балансировщик уровня 4 (TCP/UDP), pass-through архитектура

Preserve source IP (сохраняет исходный IP клиента)
Низкая latency, высокая производительность
Не терминирует SSL соединения
Работает только в одном регионе

Когда использовать: Высокопроизводительные приложения, где важен source IP

Internal Load Balancer

Что это: Внутренний балансировщик для трафика внутри VPC

Только для internal traffic
Regional scope
HTTP(S) и TCP/UDP варианты
Использует внутренние IP-адреса

Когда использовать: Микросервисная архитектура, internal API

Network Endpoint Groups (NEG)

Zonal NEG

Что это: Группа endpoints в одной зоне

Статический список IP:port
Compute Engine instances или external endpoints
Manual management

Internet NEG

Что это: External endpoints вне Google Cloud

FQDN или IP:port комбинации
Для hybrid/multi-cloud архитектур
Интеграция on-premises сервисов с GCP load balancers

Serverless NEG

Что это: Managed endpoints для serverless сервисов

Cloud Run, Cloud Functions, App Engine
Automatic scaling и health checking
Zero configuration для serverless backends

Практическое применение: NEG позволяют гибко настраивать backend-сервисы для load balancers, особенно в микросервисной архитектуре где сервисы могут быть распределены между разными платформами.

Private Service Connect vs VPC Peering

Private Service Connect (PSC)

Что это: Современный способ подключения к managed services через private endpoints

Использует internal IP-адреса
Service-specific connections
Network isolation между producer и consumer
Support для third-party services
DNS integration с private zones

Преимущества:

Более безопасно (no route overlap)
Easier firewall management
Support для cross-project connections

VPC Peering

Что это: Прямое соединение между VPC networks

Full network connectivity между VPC
Transitive routing НЕ поддерживается
Shared responsibility за firewall rules
Potential IP range conflicts

Когда использовать VPC Peering:

Когда нужна full network connectivity
Legacy applications с множественными protocols
Когда PSC не поддерживает нужный сервис

Современный подход: PSC предпочтительнее для большинства managed services (Cloud SQL, Memorystore и т.д.)

Service Account Keys vs Workload Identity Federation (OIDC)

Service Account Keys

Что это: JSON-файлы с private keys для аутентификации

Long-lived credentials (не истекают автоматически)
Security risk при неправильном хранении
Manual rotation required
Можно скачать и использовать где угодно

Проблемы:

Key sprawl (множество ключей в разных местах)
Сложность rotation
Security vulnerabilities при утечке

Workload Identity Federation (OIDC)

Что это: Федеративная аутентификация через external identity providers

Short-lived tokens
No long-lived secrets
Automatic token refresh
Integration с Kubernetes, GitHub Actions, AWS и другими

Принцип работы:

External workload получает token от своего IdP
Google STS (Security Token Service) обменивает external token на Google access token
Workload использует Google access token для доступа к GCP resources

Best Practice: Всегда используйте Workload Identity Federation вместо service account keys где это возможно

Google Cloud Storage Classes

Standard Storage

Что это: Горячее хранилище для часто используемых данных

Высокая доступность (99.95% в single region)
Низкая latency
Нет minimum storage duration
Самый дорогой storage cost, дешевые operations

Nearline Storage

Что это: Для данных, к которым обращаются < 1 раза в месяц

30-day minimum storage duration
Дешевле storage, дороже retrieval
Хорошо для backup и disaster recovery

Coldline Storage

Что это: Для данных, к которым обращаются < 1 раза в квартал

90-day minimum storage duration
Еще дешевле storage, дороже retrieval
Архивные данные, compliance

Archive Storage

Что это: Самый дешевый класс для rare access (< 1 раза в год)

365-day minimum storage duration
Самый дешевый storage, самый дорогой retrieval
Long-term archives, regulatory compliance

Lifecycle Management: Automatic transition между классами на основе age или custom rules

GKE: Autopilot vs Standard Mode

GKE Autopilot

Что это: Fully managed Kubernetes с opinionated configuration

Google управляет nodes, networking, security
Pay-per-pod model (платите только за running pods)
Предустановленные security policies
Automatic scaling и patching
Ограниченная customization

Преимущества:

Меньше operational overhead
Built-in security best practices
Cost optimization
Simplified management

Ограничения:

Нельзя SSH на nodes
Ограниченные node customizations
Некоторые workloads могут быть несовместимы

GKE Standard Mode

Что это: Traditional Kubernetes с full control

Полный контроль над nodes и cluster configuration
Pay for nodes (независимо от utilization)
Flexible networking и security options
Support для любых workloads
Больше responsibility за management

Когда использовать Standard:

Нужны custom node configurations
Legacy applications с специфическими требованиями
Specialized hardware requirements
Compliance требования с specific configurations

Выбор режима:

Autopilot: Для новых cloud-native приложений, команд без deep Kubernetes expertise
Standard: Для enterprise workloads с specific requirements, migration существующих applications

Дополнительные важные различия

Compute Engine vs Cloud Run

Compute Engine: IaaS, full control, persistent infrastructure
Cloud Run: Serverless containers, automatic scaling to zero, pay-per-request

Cloud Functions vs Cloud Run

Cloud Functions: Event-driven, specific triggers, limited runtime
Cloud Run: HTTP-driven, any containerized application, more flexibility

BigQuery vs Cloud SQL

BigQuery: Analytics warehouse, columnar storage, serverless
Cloud SQL: Transactional database, row-based, managed RDBMS

Pub/Sub vs Cloud Tasks

Pub/Sub: Messaging, many-to-many, real-time
Cloud Tasks: Task queues, point-to-point, scheduled execution

Основы Google Cloud Console

Google Cloud Console — веб-интерфейс для управления ресурсами Google Cloud Platform (GCP). Это центральная точка для администрирования проектов, сервисов, мониторинга и биллинга.

Ключевые концепции:

Проект — изолированная среда для ресурсов с собственным биллингом и настройками безопасности
Организация — корневой узел для управления несколькими проектами
Биллинговый аккаунт — связывает проекты с методом оплаты
IAM (Identity and Access Management) — система управления доступом

Навигация и структура Console

Основные элементы интерфейса

Navigation Menu — боковое меню с категориями сервисов
Project Selector — выбор активного проекта в верхней части
Cloud Shell — встроенный терминал с предустановленными инструментами
Activity Panel — история операций и уведомления
Resource Manager — иерархическое представление ресурсов

Поиск и фильтрация

Console предоставляет мощные возможности поиска:

Глобальный поиск по всем ресурсам
Фильтры по типу ресурса, региону, статусу
Сохранение часто используемых фильтров

Управление проектами

Создание и настройка проекта

Проект в GCP — это логический контейнер для ресурсов. Каждый проект имеет:

Уникальный Project ID (неизменяемый)
Project Name (можно изменить)
Project Number (автоматически генерируется)

Важные настройки проекта:

Включение необходимых API
Настройка биллинга
Конфигурация IAM политик
Установка квот и лимитов

Биллинг и мониторинг затрат

Budget Alerts — оповещения о превышении бюджета:

# Создание бюджета через gcloud CLI
gcloud billing budgets create \
    --billing-account=BILLING_ACCOUNT_ID \
    --display-name="Monthly Budget" \
    --budget-amount=1000USD

Cost Breakdown — детализация затрат по:

Сервисам
Регионам
Типам ресурсов
Временным периодам

Identity and Access Management (IAM)

Основные компоненты IAM

Principal — кто получает доступ (пользователь, группа, service account) Role — набор разрешений Policy — связывает principals с roles для конкретного ресурса

Типы ролей:

Primitive Roles — Owner, Editor, Viewer (не рекомендуется для продакшена)
Predefined Roles — готовые роли для конкретных сервисов
Custom Roles — роли с точно определенными разрешениями

Service Accounts

Service Account — специальный тип аккаунта для приложений и сервисов.

Ключевые особенности:

Используется для аутентификации приложений
Имеет JSON-ключи для авторизации
Может быть назначен VM instances
Поддерживает impersonation для делегирования прав

// Пример service account key
{
  "type": "service_account",
  "project_id": "my-project",
  "private_key_id": "key-id",
  "private_key": "-----BEGIN PRIVATE KEY-----\n...",
  "client_email": "my-service@my-project.iam.gserviceaccount.com"
}

Принципы безопасности IAM

Principle of Least Privilege — минимально необходимые права
Separation of Duties — разделение критических операций
Regular Access Review — периодический аудит доступов
Condition-based Access — доступ на основе условий (время, IP, ресурс)

Cloud Shell и CLI инструменты

Google Cloud Shell

Cloud Shell — виртуальная машина с предустановленными инструментами разработки:

5GB постоянного диска в $HOME
Предустановленные: gcloud, kubectl, terraform, docker
Интеграция с Git и популярными редакторами
Бесплатно до 50 часов в неделю

Основные gcloud команды

# Аутентификация и настройка
gcloud auth login
gcloud config set project PROJECT_ID
gcloud config set compute/region us-central1

# Управление конфигурациями
gcloud config configurations create prod
gcloud config configurations activate dev

# Получение информации о проекте
gcloud projects describe PROJECT_ID
gcloud services list --enabled

Работа с API

# Включение API сервисов
gcloud services enable compute.googleapis.com
gcloud services enable container.googleapis.com
gcloud services enable cloudsql.googleapis.com

# Просмотр доступных API
gcloud services list --available --filter="name:compute"

Мониторинг и логирование

Cloud Monitoring (Stackdriver)

Metrics — численные данные о производительности системы:

System metrics (CPU, память, диск, сеть)
Application metrics (пользовательские метрики)
Uptime checks (проверки доступности)

Alerting Policies — правила для уведомлений:

Условия срабатывания
Каналы уведомлений (email, SMS, Slack, PagerDuty)
Группировка и подавление alerts

Cloud Logging

Centralized logging для всех GCP сервисов и пользовательских приложений.

Ключевые возможности:

Structured logging (JSON формат)
Log-based metrics
Log exports в BigQuery, Cloud Storage
Real-time log streaming

# Просмотр логов через CLI
gcloud logging read "resource.type=gce_instance" --limit=10
gcloud logging read "severity>=ERROR" --format=json

Error Reporting

Автоматическое обнаружение и группировка ошибок в приложениях:

Интеграция с популярными языками (Java, Python, Node.js)
Группировка похожих ошибок
Уведомления о новых ошибках
Интеграция с системами тикетов

Сетевые сервисы и безопасность

Virtual Private Cloud (VPC)

VPC — изолированная виртуальная сеть в облаке:

Суbnets в разных регионах
Firewall rules для контроля трафика
VPC Peering для соединения сетей
Shared VPC для мультипроектных архитектур

Важные концепции:

CIDR blocks — диапазоны IP адресов
Route tables — маршрутизация трафика
Network tags — метки для группировки ресурсов
Private Google Access — доступ к GCP API без внешних IP

Cloud Load Balancing

Global Load Balancer — распределение трафика между регионами:

HTTP(S) Load Balancer для веб-трафика
TCP/UDP Load Balancer для других протоколов
Internal Load Balancer для внутреннего трафика

Backend Services — группы экземпляров, обслуживающих запросы:

Health checks для проверки доступности
Session affinity для sticky sessions
Auto-scaling на основе нагрузки

Cloud CDN

Content Delivery Network для ускорения доставки контента:

Кэширование статического контента
Интеграция с Load Balancer
Cache invalidation для обновления контента
SSL/TLS терминация

Database сервисы

Cloud SQL

Managed relational databases (MySQL, PostgreSQL, SQL Server):

Автоматические бэкапы и point-in-time recovery
High Availability с автоматическим failover
Read replicas для масштабирования чтения
Private IP для безопасного подключения

Настройка для Java приложений:

// Connection pooling с HikariCP
HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:postgresql://CLOUD_SQL_IP:5432/database");
config.setUsername("user");
config.setPassword("password");
config.setMaximumPoolSize(10);

Cloud Firestore

NoSQL document database:

ACID транзакции
Real-time synchronization
Offline support для мобильных приложений
Multi-region replication

Cloud Spanner

Globally distributed relational database:

Horizontal scaling
Strong consistency
SQL support
Automatic sharding

Compute сервисы

Compute Engine

Virtual machines в облаке:

Предконфигурированные и custom machine types
Persistent disks для хранения данных
Instance groups для автоматического масштабирования
Spot instances для экономии на нерегулярных задачах

Instance Templates — шаблоны для создания однотипных VM:

Startup scripts для автоматической настройки
Metadata для передачи конфигурации
Network tags для firewall правил

Google Kubernetes Engine (GKE)

Managed Kubernetes кластеры:

Autopilot mode — полностью управляемые узлы
Standard mode — больше контроля над конфигурацией
Workload Identity для безопасной интеграции с GCP
Binary Authorization для проверки образов

# Создание GKE кластера
gcloud container clusters create my-cluster \
    --zone=us-central1-a \
    --num-nodes=3 \
    --enable-autoscaling \
    --min-nodes=1 \
    --max-nodes=10

Cloud Run

Serverless containers для микросервисов:

Автоматическое масштабирование до нуля
Pay-per-request модель
Поддержка любых языков и runtime
Traffic splitting для канареечных деплойментов

CI/CD и Developer Tools

Cloud Build

Managed CI/CD сервис:

Интеграция с GitHub, Bitbucket, Cloud Source Repositories
Docker образы и custom build steps
Triggers на push, PR, manual
Secrets management для конфиденциальных данных

# cloudbuild.yaml пример
steps:

- name: 'gcr.io/cloud-builders/mvn'
  args: ['clean', 'compile', 'test']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/my-app', '.']

Artifact Registry

Хранилище артефактов для Docker images, Maven packages, npm packages:

Vulnerability scanning
Access control через IAM
Regional и multi-regional repositories
Integration с CI/CD pipelines

Cloud Source Repositories

Private Git repositories в GCP:

Интеграция с Cloud Build
Code search и review
Mirroring с GitHub/Bitbucket
Stackdriver Debugger integration

Практические советы для Senior разработчика

Архитектурные паттерны

Multi-tier architecture — разделение на presentation, application, data layers
Microservices — использование Cloud Run, GKE для независимых сервисов
Event-driven — Pub/Sub для асинхронного взаимодействия
Data pipeline — Dataflow для обработки больших объемов данных

Безопасность и compliance

VPC Service Controls — периметр безопасности для данных
Binary Authorization — проверка подписей контейнеров
Cloud KMS — управление ключами шифрования
Audit Logs — логирование всех административных действий

Производительность и оптимизация

Caching strategies — Cloud Memorystore для Redis/Memcached
Database optimization — connection pooling, read replicas
CDN usage — Cloud CDN для статического контента
Monitoring — custom metrics для бизнес-логики

Disaster Recovery

RTO/RPO planning — определение требований к восстановлению
Cross-region backups — резервирование в нескольких регионах
Infrastructure as Code — Terraform для воспроизводимой инфраструктуры
Chaos engineering — тестирование отказоустойчивости

Cost optimization

Resource rightsizing — подбор оптимального размера ресурсов
Committed use discounts — скидки за долгосрочные обязательства
Preemptible instances — экономия на прерываемых VM
Lifecycle policies — автоматическое удаление старых данных

Интеграция с Java экосистемой

Spring Boot на GCP

Cloud SQL для реляционных баз данных
Cloud Storage для файлового хранилища
Cloud Pub/Sub для messaging
Cloud Trace для distributed tracing

Библиотеки и SDK

// Google Cloud Client Libraries
implementation 'com.google.cloud:google-cloud-storage'
implementation 'com.google.cloud:google-cloud-pubsub'
implementation 'com.google.cloud:google-cloud-logging'

Мониторинг Java приложений

Micrometer интеграция с Cloud Monitoring
OpenTelemetry для трейсинга
Health checks для Kubernetes liveness/readiness probes