Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Это метод развертывания, при котором новая версия приложения разворачивается в продакшен среде, но не обрабатывает пользовательские запросы напрямую. Вместо этого, новая версия работает в фоновом режиме, обрабатывая копии реальных запросов или синтетические запросы для проверки и мониторинга.
Новая версия разворачивается вместе с текущей версией, но не обслуживает реальные пользовательские запросы.
Новая версия обрабатывает копии запросов, направляемых на текущую версию, или синтетические запросы, созданные для тестирования. Результаты работы новой версии сравниваются с результатами текущей версии для выявления проблем.
После успешного тестирования новая версия начинает обслуживать реальные запросы.
Тестирование новой версии в реальной продакшен среде без воздействия на пользователей.
Возможность обнаружения проблем до того, как новая версия начнет обслуживать реальные запросы.
Сравнение производительности новой версии с текущей в реальных условиях.
Новая версия приложения развернута в продакшен среде.
Новая версия получает копии реальных запросов.
Результаты обработки копий запросов сравниваются с результатами текущей версии.
После успешного тестирования новая версия начинает обрабатывать реальные запросы.
Это метод развертывания, при котором одновременно используются две версии приложения (A и B), каждая из которых обрабатывает часть пользовательских запросов. Этот метод позволяет сравнивать производительность и поведение двух версий в реальных условиях.
Версия A (текущая версия) и версия B (новая версия) развернуты в продакшен среде.
Трафик распределяется между двумя версиями по определенной пропорции (например, 50% на A и 50% на B).
Производительность и поведение двух версий сравниваются для определения лучшей версии.
Возможность сравнивать две версии приложения в реальных условиях.
Получение реальных данных о предпочтениях пользователей и производительности.
Возможность плавного перехода от старой версии к новой, основываясь на результатах сравнения.
Текущая версия (A) и новая версия (B) развернуты в продакшен среде.
Балансировщик нагрузки распределяет трафик между A и B.
Производительность и поведение версий сравниваются.
На основе анализа выбирается лучшая версия для полного развертывания.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Это формальный договор между поставщиком услуги и клиентом, определяющий уровень обслуживания, который поставщик обязуется предоставить. SLA описывает конкретные измеримые аспекты сервиса, такие как доступность, производительность, время отклика, а также механизмы разрешения инцидентов и компенсации за несоблюдение договоренностей.
Описание услуг, которые предоставляет поставщик, и их характеристики.
Гарантированный процент времени, в течение которого услуга будет доступна (например, 99.9% времени).
Показатели производительности, такие как время отклика, пропускная способность и другие метрики.
Среднее время, необходимое для восстановления сервиса после сбоя.
Среднее время на принятие мер после обнаружения проблемы.
Описание уровней поддержки, доступных клиенту (например, 24/7 поддержка, время реакции на запросы).
Механизмы уведомления клиента о проблемах и процедуры эскалации в случае серьезных инцидентов.
Механизмы компенсации клиенту за несоблюдение SLA, такие как кредиты или скидки на услуги.
Описание методов и частоты мониторинга выполнения SLA, а также предоставление отчетов клиенту.
"Поставщик обязуется предоставлять услуги хостинга для веб-приложений клиента с использованием своих дата-центров."
"Услуга будет доступна не менее 99.9% времени в течение календарного месяца."
"Среднее время отклика сервиса не должно превышать 200 миллисекунд."
"Среднее время восстановления после сбоя не должно превышать 4 часов."
"Поставщик обязуется предоставлять круглосуточную поддержку с максимальным временем реакции на запросы не более 30 минут."
"В случае несоблюдения уровня доступности 99.9%, клиент имеет право на компенсацию в виде 10% кредита за каждый час простоя."
SLA устанавливает четкие ожидания относительно уровня обслуживания, что снижает недоразумения между поставщиком и клиентом.
SLA способствует ответственности поставщика за предоставляемые услуги и позволяет клиенту контролировать их качество.
SLA помогает управлять рисками, связанными с отказами или снижением качества обслуживания, и обеспечивает механизмы компенсации.
Наличие SLA повышает доверие клиентов к поставщику, демонстрируя его готовность поддерживать высокий уровень обслуживания.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Это конкретное, измеримое значение, которое сервис должен достичь или превзойти. SLO является частью соглашения об уровне обслуживания (SLA) и определяет цели производительности, доступности и других метрик, которые организация обязуется поддерживать.
Процент времени, в течение которого услуга должна быть доступна. Пример: "Услуга будет доступна не менее 99.9% времени в течение календарного месяца."
Показатели производительности, такие как время отклика или пропускная способность. Пример: "Среднее время отклика сервиса не должно превышать 200 миллисекунд."
Среднее время, необходимое для восстановления сервиса после сбоя. Пример: "Среднее время восстановления после сбоя не должно превышать 4 часов."
Среднее время на принятие мер после обнаружения проблемы. Пример: "Среднее время реакции на инцидент не должно превышать 30 минут."
Допустимый процент ошибок в запросах. Пример: "Процент ошибочных запросов не должен превышать 0.1%."
"Сервис должен быть доступен 99.95% времени в течение календарного месяца."
"Среднее время отклика для 95% запросов не должно превышать 200 миллисекунд."
"Среднее время восстановления после инцидента не должно превышать 1 час."
"Процент запросов, завершающихся ошибкой, не должен превышать 0.5%."
Соглашение между поставщиком услуги и клиентом, которое включает SLO и описывает уровень обслуживания, который должен быть достигнут. SLA часто включает последствия за невыполнение SLO, такие как компенсации или штрафы.
Конкретная цель или метрика, которая определяет, какого уровня обслуживания должен достигать сервис. SLO — это часть SLA.
SLO позволяет измерять и контролировать качество предоставляемых услуг, что помогает поддерживать высокий уровень обслуживания.
Определение SLO помогает управлять ожиданиями клиентов и внутренних команд, устанавливая четкие цели и стандарты.
SLO служат основой для мониторинга производительности и выявления областей, требующих улучшения.
SLO помогают управлять рисками, связанными с недостижением целей обслуживания, и обеспечивают проактивные меры для их предотвращения.
"Сервис должен быть доступен 99.9% времени."
"Среднее время отклика для 95% запросов не должно превышать 300 миллисекунд."
"Среднее время восстановления после инцидента не должно превышать 30 минут."
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Это конкретная метрика, используемая для измерения качества обслуживания сервиса. SLI показывает, насколько хорошо сервис соответствует определенным критериям, установленным в SLO (Service Level Objective).
Процент времени, в течение которого сервис доступен для пользователей. Пример: "99.9% времени в течение месяца."
Метрики, такие как время отклика или пропускная способность. Пример: "Среднее время отклика 200 миллисекунд."
Среднее время, необходимое для восстановления сервиса после сбоя. Пример: "Среднее время восстановления 1 час."
Среднее время на принятие мер после обнаружения проблемы. Пример: "Среднее время реакции на инцидент 30 минут."
Процент запросов, завершающихся ошибкой. Пример: "Процент ошибочных запросов не более 0.1%."
"Сервис был доступен 99.95% времени за последний месяц."
"Среднее время отклика сервиса за последний месяц составило 150 миллисекунд."
"Среднее время восстановления сервиса после сбоев за последний месяц составило 45 минут."
"Процент ошибочных запросов за последний месяц составил 0.05%."
Соглашение между поставщиком услуги и клиентом, включающее SLO и описывающее уровень обслуживания, который должен быть достигнут. SLA может включать последствия за невыполнение SLO.
Конкретные цели или метрики, которые определяют уровень обслуживания, которого должен достигнуть сервис. SLO являются частью SLA.
Конкретные метрики, используемые для измерения фактической производительности сервиса относительно установленных SLO. SLI — это количественные показатели, которые служат основой для SLO.
SLI позволяют количественно измерять различные аспекты работы сервиса, такие как доступность и производительность.
SLI используются для постоянного мониторинга сервиса и обеспечения соответствия установленным SLO.
SLI помогают выявлять проблемы в работе сервиса и принимать меры для их устранения.
Анализ SLI позволяет улучшать качество обслуживания путем выявления и устранения узких мест и проблем.
SLI: "99.9% времени сервис доступен."
SLO: "Сервис должен быть доступен не менее 99.9% времени в течение месяца."
SLA: "Если доступность падает ниже 99.9%, клиент получает компенсацию."
SLI: "Среднее время отклика 200 миллисекунд."
SLO: "Среднее время отклика не должно превышать 250 миллисекунд для 95% запросов."
SLA: "Если время отклика превышает 250 миллисекунд, клиент получает компенсацию."
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Помогают автоматизировать процесс сборки, тестирования и развертывания приложений, повышая эффективность и качество разработки.
Один из самых популярных и широко используемых инструментов CI/CD с открытым исходным кодом.
Плюсы и минусы:
Встроенный в GitLab инструмент для CI/CD.
Плюсы и минусы:
Облачный сервис CI/CD, который также предлагает возможности для локального развертывания.
Плюсы и минусы:
Облачный CI/CD сервис, популярный среди проектов с открытым исходным кодом.
Плюсы и минусы:
Инструмент CI/CD от Atlassian, хорошо интегрированный с другими продуктами Atlassian, такими как Jira и Bitbucket.
Плюсы и минусы:
Инструмент CI/CD от JetBrains.
Плюсы и минусы:
Набор инструментов от Microsoft для управления полным циклом разработки, включающий CI/CD.
Плюсы и минусы:
Встроенный в GitHub инструмент для автоматизации рабочих процессов, включая CI/CD.
Плюсы и минусы:
Облачный сервис CI/CD, ориентированный на простоту использования и интеграцию с GitHub и Bitbucket.
Плюсы и минусы:
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Обеспечение непрерывности и стабильности деплоя приложения требует внедрения множества практик и использования различных инструментов. Важные аспекты включают автоматизацию, тестирование, мониторинг и использование современных методик развертывания.
CI/CD (Continuous Integration / Continuous Deployment): Настройте конвейер CI/CD, чтобы автоматизировать процесс сборки, тестирования и развертывания. Используйте инструменты, такие как Jenkins, GitLab CI/CD, GitHub Actions, CircleCI, и другие для автоматизации этих процессов.
Юнит-тесты (Unit Tests): Пишите тесты для отдельных компонентов приложения, чтобы проверять их корректность.
Интеграционные тесты (Integration Tests): Проверяйте взаимодействие между различными компонентами системы.
Системные тесты (System Tests): Тестируйте приложение целиком в среде, максимально приближенной к продакшену.
Пример юнит-теста на Go:
package main
import (
"testing"
)
func TestAdd(t *testing.T) {
result := Add(2, 3)
if result != 5 {
t.Errorf("Expected 5, but got %d", result)
}
}
Blue-Green Deployment: Используйте две идентичные среды (синюю и зеленую) для развертывания новой версии и переключения трафика между ними.
Canary Deployment: Внедряйте новую версию постепенно, направляя небольшой процент трафика на новую версию и увеличивая его по мере уверенности в стабильности.
Пример настройки Blue-Green Deployment:
1. Разверните новую версию на зеленой среде.
2. Тестируйте зеленую среду.
3. Переключите трафик с синей на зеленую среду.
4. Следите за состоянием новой версии.
5. В случае проблем вернитесь к синей среде.
Мониторинг: Используйте инструменты мониторинга (Prometheus, Grafana, New Relic) для отслеживания состояния приложения в реальном времени.
Логирование: Сбор и анализ логов (ELK Stack, Splunk) для выявления и устранения проблем.
Пример использования Prometheus для мониторинга:
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'my_app'
static_configs:
- targets: ['localhost:9090']
Обратная связь: Регулярно собирайте и анализируйте обратную связь от пользователей и команды разработчиков.
Инцидент-менеджмент: Внедрите процессы для быстрого реагирования на инциденты и восстановления работоспособности (например, использование инструмента PagerDuty).
Автоматизация инфраструктуры: Используйте инструменты IaC (Terraform, Ansible) для автоматизации настройки и управления инфраструктурой.
Пример использования Terraform:
provider "aws" {
region = "us-west-2"
}
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}Контейнеризация: Используйте Docker для контейнеризации приложений, что упрощает их развертывание и масштабирование.
Оркестрация: Используйте Kubernetes для оркестрации контейнеров, обеспечивая высокую доступность и масштабируемость.
Пример Dockerfile:
FROM node:14
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["npm", "start"]
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
В процессе деплоя продукта могут возникать различные проблемы, которые требуют быстрого и эффективного решения.
Проблема: Новая версия приложения несовместима с существующими библиотеками, сервисами или API.
Митигация
Автоматическое тестирование: Внедрение автоматических юнит-тестов и интеграционных тестов для проверки совместимости.
Канареечное развертывание: Постепенное внедрение новой версии для небольшого процента пользователей и мониторинг на предмет несовместимостей.
Контейнеризация: Использование Docker для создания изолированных окружений, что обеспечивает согласованность зависимостей.
Проблема: Время простоя сервиса во время деплоя новой версии.
Митигация
Blue-Green Deployment: Использование двух идентичных сред (синяя и зеленая) для развертывания и переключения трафика между ними.
Rolling Updates: Постепенное обновление экземпляров приложения, что позволяет минимизировать время простоя.
Проблема: Деплой новой версии приложения завершился с ошибками.
Митигация
Автоматическое откатывание (rollback): Внедрение механизмов автоматического отката к предыдущей стабильной версии в случае неудачного деплоя.
CI/CD Pipeline: Использование CI/CD для автоматизации тестирования и развертывания, что помогает выявлять проблемы на ранних этапах.
Проблема: Новая версия приложения вызывает проблемы с производительностью.
Митигация
Performance Testing: Внедрение нагрузочного тестирования для проверки производительности перед развертыванием.
Мониторинг и алертинг: Настройка мониторинга (Prometheus, Grafana) и системы оповещения для быстрого реагирования на проблемы с производительностью.
Проблема: Изменения в схеме базы данных приводят к проблемам с доступом или потерей данных.
Митигация
Миграции базы данных: Использование инструментов для миграции базы данных (Liquibase, Flyway) для управления изменениями схемы.
Бэкапы: Регулярное создание резервных копий базы данных и возможность быстрого восстановления данных в случае сбоя.
Проблема: Некорректные настройки конфигурации приводят к сбоям в работе приложения.
Митигация
Среда исполнения: Разделение конфигураций по средам (dev, staging, production) и использование файлов конфигурации или переменных окружения.
Секреты: Безопасное управление секретами и конфиденциальными данными с помощью инструментов (HashiCorp Vault, AWS Secrets Manager).
Проблема: Уязвимости в новой версии приложения, которые могут быть использованы для атак.
Митигация
Security Testing: Внедрение инструментов для статического и динамического анализа безопасности (SonarQube, OWASP ZAP).
Автоматические обновления: Регулярное обновление зависимостей и библиотек для устранения известных уязвимостей.
Автоматическое тестирование и канареечное развертывание:
name: CI/CD Pipeline
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Node.js
uses: actions/setup-node@v1
with:
node-version: '14'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
- name: Build project
run: npm run build
- name: Deploy to staging
run: ./deploy.sh staging
- name: Canary deployment
run: ./deploy.sh canary
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
В Go, проверка типа интерфейса может быть выполнена несколькими способами: с помощью утверждения типа (type assertion) и с помощью конструкции
switch для выбора типа. Утверждение типа позволяет проверить, является ли значение определенного интерфейса конкретным типом. Если да, то оно преобразует интерфейс в этот тип.
value, ok := interfaceValue.(ConcreteType)
valueЗначение типа
ConcreteType, если утверждение типа успешно.okБулевое значение, указывающее, удалось ли преобразование.
package main
import "fmt"
func main() {
var i interface{} = "hello"
// Утверждение типа
s, ok := i.(string)
if ok {
fmt.Println("String:", s)
} else {
fmt.Println("Not a string")
}
// Утверждение типа, которое вызовет панику, если тип не соответствует
// Uncomment the line below to see the panic
// s := i.(string)
// fmt.Println(s)
}
Конструкция
switch позволяет проверить значение интерфейса на соответствие нескольким возможным типам.switch v := interfaceValue.(type) {
case ConcreteType1:
// v имеет тип ConcreteType1
case ConcreteType2:
// v имеет тип ConcreteType2
default:
// v имеет другой тип
}package main
import "fmt"
func printType(i interface{}) {
switch v := i.(type) {
case string:
fmt.Println("String:", v)
case int:
fmt.Println("Integer:", v)
case bool:
fmt.Println("Boolean:", v)
default:
fmt.Printf("Unknown type: %T\n", v)
}
}
func main() {
printType("hello")
printType(42)
printType(true)
printType(3.14)
}
Пример использования для проверки и работы с интерфейсами
package main
import (
"fmt"
)
type Person struct {
Name string
Age int
}
// Реализация интерфейса fmt.Stringer для типа Person
func (p Person) String() string {
return fmt.Sprintf("%s (%d years old)", p.Name, p.Age)
}
func printValue(i interface{}) {
if str, ok := i.(fmt.Stringer); ok {
fmt.Println("Stringer:", str.String())
} else {
fmt.Println("Not a Stringer")
}
}
func main() {
p := Person{Name: "Alice", Age: 30}
printValue(p) // Проверка типа fmt.Stringer
printValue("Hello, world!") // Строка не реализует fmt.Stringer
}
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
В Go пустой интерфейс
interface{} является особым типом, который может содержать значение любого типа. Это связано с тем, что в Go любой тип реализует пустой интерфейс, поскольку в нем нет методов, которые нужно реализовать. Поскольку пустой интерфейс не требует реализации каких-либо методов, любой тип в Go автоматически реализует этот интерфейс. Это делает пустой интерфейс универсальным контейнером для значений любых типов.
type interface{} interface {}Типа конкретного значения
Самого значения
Когда значение присваивается переменной типа интерфейс, Go сохраняет информацию о типе и значении этого значения. Для пустого интерфейса эта информация может быть любого типа.
Когда значение из пустого интерфейса приводится к конкретному типу, происходит проверка типа во время выполнения. Если значение внутри интерфейса действительно является указанным типом, приведение успешно. В противном случае приведение не удается, и возвращается значение
nil или происходит паника, если приведение выполнено без проверки.Присваивание значений пустому интерфейсу
package main
import "fmt"
func main() {
var i interface{}
i = 42
fmt.Println(i) // 42
i = "hello"
fmt.Println(i) // hello
}
Утверждение типа (Type Assertion)
package main
import "fmt"
func main() {
var i interface{} = "hello"
// Утверждение типа с проверкой
s, ok := i.(string)
if ok {
fmt.Println("String:", s)
} else {
fmt.Println("Not a string")
}
// Утверждение типа без проверки
// Это вызовет панику, если тип не соответствует
s = i.(string)
fmt.Println("String:", s)
}
Использование switch для проверки типа
package main
import "fmt"
func printType(i interface{}) {
switch v := i.(type) {
case string:
fmt.Println("String:", v)
case int:
fmt.Println("Integer:", v)
case bool:
fmt.Println("Boolean:", v)
default:
fmt.Printf("Unknown type: %T\n", v)
}
}
func main() {
printType("hello")
printType(42)
printType(true)
printType(3.14)
}
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Интерфейсы играют важную роль, позволяя абстрагироваться от конкретных реализаций и работать с различными типами данных через общий интерфейс. Пустой интерфейс
interface{} имеет особое значение, так как может содержать значение любого типа. Понимание того, как пустой интерфейс связан с обычными интерфейсами, важно для эффективного использования Go. Пустой интерфейс не требует реализации никаких методов, что делает его универсальным контейнером для значений любого типа. Любой тип в Go автоматически реализует пустой интерфейс, поскольку в нем нет методов, которые нужно реализовать.
type interface{} interface {}Обычные интерфейсы определяют один или несколько методов, которые тип должен реализовать, чтобы считаться реализацией этого интерфейса.
type Stringer interface {
String() string
}Типы, реализующие обычные интерфейсы, автоматически реализуют и пустой интерфейс, поскольку пустой интерфейс не требует реализации методов.
Пустой интерфейс может быть использован для написания обобщенного кода, который работает с любыми типами.
Значение, хранящееся в пустом интерфейсе, можно привести к любому конкретному типу или интерфейсу с помощью утверждения типа (type assertion) или конструкции
switch.Присваивание значений пустому интерфейсу и проверка типов
package main
import "fmt"
func main() {
var i interface{}
i = "hello"
fmt.Println(i) // hello
i = 42
fmt.Println(i) // 42
// Проверка типа через утверждение
if s, ok := i.(int); ok {
fmt.Println("Integer:", s)
} else {
fmt.Println("Not an integer")
}
// Приведение типа через switch
switch v := i.(type) {
case string:
fmt.Println("String:", v)
case int:
fmt.Println("Integer:", v)
default:
fmt.Printf("Unknown type: %T\n", v)
}
}
Пустой интерфейс и обычный интерфейс
package main
import "fmt"
// Обычный интерфейс
type Stringer interface {
String() string
}
// Тип, реализующий обычный интерфейс
type Person struct {
Name string
Age int
}
func (p Person) String() string {
return fmt.Sprintf("%s (%d years old)", p.Name, p.Age)
}
func printValue(i interface{}) {
if str, ok := i.(Stringer); ok {
fmt.Println("Stringer:", str.String())
} else {
fmt.Println("Not a Stringer")
}
}
func main() {
p := Person{Name: "Alice", Age: 30}
printValue(p) // Проверка типа Stringer
printValue("Hello, world!") // Строка не реализует Stringer
}
информация о типе значения, хранящегося в интерфейсе.
само значение.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Классический цикл с условиями (for i := 0; i < 10; i++).
Цикл с проверкой условия (for i < 10).
Бесконечный цикл (for {}), который останавливается вручную через break.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM