Системний адміністратор — не DevOps-інженер. Розбір вакансій, технологій та обов’язків

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Павло, у сфері системного адміністрування та DevOps я вже понад 15 років, тож про різницю між сисадміном та DevOps-інженером знаю не з чуток.

Є думка, що професії DevOps-інженер не існує, і цю роботу може виконувати просто скіловий системний адміністратор. Через це ми й бачимо вакансії, де рекрутери шукають сисадміна на відповідну зарплату, проте прописують обов’язки та вимоги як до DevOps-інженера.

Ось кілька рандомних прикладів:





У матеріалі хочу пояснити, що такі вакансії не о’кей та чому. DevOps-фахівець та системний адміністратор — це різні спеціальності. Наймом сисадміна не можна закрити потребу в DevOps-інженері: для виконання задач команди DevOps треба мати специфічні знання та навички.

Що робить системний адміністратор

Сисадмін — це фахівець, який займається налаштуванням та підтримкою IT-інфраструктури в компанії.

На те, що конкретно входить у його обов’язки, впливає досвід спеціаліста та сама компанія: кількість працівників, як побудовані процеси, тощо. Якщо це сисадмін-енікей, він виконує базову роботу з налаштування ПЗ та обладнання. А якщо ми говоримо про більш досвідченого спеціаліста, він має розумітися на розробці, займатися мережами та безпекою IT-інфраструктури.

Задачі системного адміністратора можна звести до п’яти пунктів:

  • керування інфраструктурою: налаштування всього обладнання та ПЗ, забезпечення безперебійної роботи серверів, оновлення ПЗ;
  • керування дозволами та доступом користувачів: керування реєстрацією колег та політикою SSO, дотримання вимог безпеки;
  • відновлення безпеки та резервне копіювання: створення копій на випадок, якщо щось піде не так з сервером або програмою, відновлення роботи серверів після проблеми;
  • усунення несправностей: розв’язання проблем і пошук рішень для підтримки безпеки компанії;
  • моніторинг інфраструктури: відстеження показників ЦП, DNS, використання, затримки тощо.

Хто такий DevOps-інженер

DevOps-інженери також відповідають за безперервну роботу інфраструктури компанії. Але, на відміну від сисадмінів, вони не зосереджені лише на цьому, а й працюють над покращенням розробки продуктів, координацією та оптимізацією процесів.

Однією з основних задач DevOps-інженера є впровадження автоматизації процесів. Таким чином співпраця між командами полегшиться, не буде потреби в ручному виконанні більшості рутинних задач, а створення, тестування та розгортання програмного забезпечення стане більш ефективним. Ця автоматизація більшою мірою здійснюється за допомогою хмарних служб.

Обов’язки DevOps-інженерів можуть відрізнятися у кожній компанії, проте до основних задач належать:

  • автоматизація процесів розробки та релізів;
  • налагодження процесів CI/CD;
  • конфігурування та розгортання інфраструктури;
  • налаштування мереж та хмарних систем;
  • моніторинг та централізоване логування;
  • впровадження безпекових заходів та захист систем;
  • співпраця з розробниками.

Чому сисадмін та DevOps-інженер — це різні професії

Отже сисадміни та DevOps-інженери мають різні обов’язки. Сисадміни не беруть участь у процесі розробки ПЗ, що робить різницю між ними та розробниками досить очевидною. DevOps-інженери відіграють більш активну роль, зосереджуючись на життєвому циклі продукту, а системні адміністратори втручаються лише на етапі його проєктування.

Крім різних задач ці спеціалісти мають також різні цілі. Мета DevOps-інженера — забезпечити співпрацю між командами та системами всередині компанії. Системний адміністратор головно зосереджується на конфігурації та обслуговуванні комп’ютерних систем і серверів компанії.

Зрозуміло, що для роботи цим спеціалістам необхідно мати різні скіли. Тому перейти з системного адміністрування у DevOps без додаткової підготовки та навчання майже неможливо. Ось якими навичками та знаннями має володіти кандидат на посаду DevOps-інженера:

  • розуміння основ Linux;
  • володіння LEMP-стеком;
  • досвід використання або розуміння роботи з хмарними провайдерами;
  • навички автоматизації;
  • навички віртуалізації;
  • досвід використання або розуміння роботи з контейнерними технологіями;
  • навички оркестрування;
  • навички моніторингу та логування;
  • розуміння процесів CI/CD.

Після переходу в DevOps збільшиться кількість обов’язків, складність завдань, а сам фахівець має постійно навчатися.

Працювати DevOps-інженером непросто, бо на ньому лежить багато відповідальності, йому необхідно взаємодіяти майже з усією компанією.

Проте це компенсується вищими зарплатами — DevOps-інженер заробляє у три рази більше, ніж системний адміністратор. Про це свідчить статистика DOU за червень 2023 року: медіанна зарплата сисадміна становить $1,100, а у DevOps-інженера — $3,500.

Які технології використовують сисадміни та DevOps-інженери

Системні адміністратори та DevOps-інженери використовують різні інструменти залежно від завдань та вимог конкретного проєкту. Виокремимо загальні технології, які використовуються для цих професій.

Технології та інструменти, якими користуються системні адміністратори:

  • адміністрування операційних систем: Linux, Windows;
  • адміністрування баз даних: SQL, MySQL, PostgreSQL;
  • адміністрування вебсерверів: Apache, Nginx;
  • IP-телефонія: Asteris;
  • віртуалізація: OpenVZ, Proxmox, VMware, VirtualBox, Hyper-V;
  • системи керування версіями: GitLab, GitHub;
  • системи управління конфігураціями: Ansible;
  • моніторинг та логування: Zabbix, Prometheus, Grafana, Alerta, ELK-стек;
  • хмарна інфраструктура: Amazon AWS, Microsoft Azure, Google Cloud Platform.

Останні інструменти використовуються переважно спеціалістами рівня Middle чи Senior.

Технології та інструменти, якими користуються DevOps-інженери:

  • CI/CD: Jenkins, Travis CI, GitLab CI/CD, CircleCI;
  • контейнеризація: Docker, Docker Compose;
  • оркестрування: Kubernetes, Docker Swarm;
  • Infrastructure as a Code: Terraform, AWS CloudFormation, Terragrunt, Pulumi;
  • технології та інструменти, що використовують сисадміни.

Які ролі існують в DevOps-команді

Як я вже згадував, обов’язки DevOps-інженерів відрізняються залежно від компанії. Для деяких проєктів існує потреба не лише в одному фахівці, а у цілій DevOps-команді. До неї можуть входити не тільки DevOps Engineer, а й SRE, DevOps Architect, Cloud DevOps Engineer, Release Manager, Cyber Security Engineer, SysOps Administrator тощо.

Розберемо деякі з них

DevOps System Engineer відповідає за збереження інфраструктури. Він повинен мати досвід моніторингу і підтримки систем, вміти створювати високодоступні, відмовостійкі системи, працювати з хмарними обчисленнями.

Ось орієнтовний стек, що я сформував на основі власних спостережень:

  • Операційні системи: Linux (Ubuntu, CentOS, Debian, Red Hat).
  • Віртуалізація та контейнеризація: Docker, Kubernetes, VMware, AWS Elastic Container Service (ECS), Azure Container Instances.
  • Хмарні платформи: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP).
  • Системи управління конфігураціями та автоматизації: Ansible, Chef, Puppet, Terraform.
  • Системи моніторингу та логування: Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana), Splunk.
  • Системи керування версіями коду: Git, GitHub, GitLab, Bitbucket.
  • CI/CD інструменти: Jenkins, GitLab CI/CD, CircleCI, Travis CI.
  • Системи управління контейнерами та образами: Docker Registry, Harbor, Amazon ECR (Elastic Container Registry), Azure Container Registry.
  • Мережеві технології: TCP/IP, HTTP/HTTPS, DNS, Load Balancers.
  • Системи моніторингу продуктивності: New Relic, AppDynamics, Datadog, Nagios.
  • Бази даних та сховища даних: MySQL, PostgreSQL, MongoDB, Redis.
  • Безпека та керування доступом: IAM (Identity and Access Management), LDAP (Lightweight Directory Access Protocol), Security Groups, VPN (Virtual Private Network) configurations.

DevOps Security Engineer відповідає за безпеку продукту, оцінює його захищеність та створює план протидії загрозам. Він має чітко розуміти безпеку систем та мереж, оцінювати ймовірність виникнення певних загроз та складати план на випадок їхнього виникнення, мати вичерпні знання щодо безпеки у хмарі та розумітися на тестуванні на проникнення.

Я сформував орієнтовний стек на основі власних спостережень:

  • Інструменти сканування вразливостей: Nessus, Qualys, OpenVAS, Nikto.
  • Інструменти аналізу конфігурації безпеки: Chef InSpec, Puppet Remediate, Ansible Vault.
  • Інструменти контейнерної безпеки: Docker Bench for Security, Clair, Anchore, Twistlock.
  • Інструменти виявлення вторгнень (IDS/IPS): Snort, Suricata, Security Onion, OSSEC.
  • Системи централізованого журналювання та моніторингу безпеки: ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, Graylog, OSSIM (Open Source Security Information Manager).
  • Інструменти управління та аналізу журналів безпеки: Security Information and Event Management (SIEM) системи, LogRhythm, IBM QRadar, McAfee Enterprise Security Manager (ESM).
  • Інструменти шифрування даних та управління ключами: OpenSSL, HashiCorp Vault, Amazon KMS (Key Management Service), Azure Key Vault.
  • Інструменти автоматизації безпеки: HashiCorp Terraform, Chef Automate, Puppet Bolt, Ansible Security Automation.
  • Інструменти аудиту та відповідності: OpenSCAP, Chef Compliance, Nessus Compliance Checks, Qualys Policy Compliance.
  • Інструменти захисту периметра та мережевої безпеки: Firewall (наприклад, iptables, pfSense), VPN (Virtual Private Network) рішення (наприклад, OpenVPN, Cisco AnyConnect), Web Application Firewalls (WAF) (наприклад, ModSecurity, AWS WAF), DDoS-захист (наприклад, Cloudflare, AWS Shield).

Cloud DevOps Engineer працює з хмарними сервісами для швидкого та надійного розгортання програмного забезпечення. Він також керує інфраструктурою в хмарі та займається її оптимізацією.

Ось орієнтовний стек, сформований на основі власного досвіду:

  • Хмарні платформи: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), IBM Cloud, Oracle Cloud Infrastructure (OCI).
  • Інфраструктура як код (IaC): Terraform, AWS CloudFormation, Azure Resource Manager (ARM) Templates, Google Cloud Deployment Manager.
  • Контейнеризація та оркестрування: Docker, Kubernetes, Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE).
  • Системи керування конфігураціями: Ansible, Puppet, Chef, AWS OpsWorks, Azure Automation.
  • CI/CD інструменти: Jenkins, GitLab CI/CD, CircleCI, Travis CI, AWS CodePipeline, Azure DevOps Pipelines.
  • Моніторинг та логування: Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana), AWS CloudWatch Azure Monitor, Google Cloud Monitoring.
  • Сховища даних та бази даних: Amazon RDS (Relational Database Service), Amazon DynamoDB, Azure SQL Database, Google Cloud SQL, MongoDB Atlas, Redis Labs.
  • Системи управління версіями коду та спільної роботи: Git, GitHub, GitLab, Bitbucket.
  • Мережеві технології: Virtual Private Clouds (VPC), AWS Direct Connect, Azure Virtual Network, Google Cloud Virtual Private Cloud (VPC).
  • IAM: AWS IAM, Azure Active Directory, Google Cloud Identity and Access Management (IAM).
  • Секрети та управління доступом: AWS Secrets Manager, Azure Key Vault, HashiCorp Vault.
  • Автоматизація резервного копіювання та відновлення: AWS Backup, Azure Backup, Google Cloud Storage.

DevOps Testing Professional займається написанням автоматизованих тестів для ПЗ, що розробляється. Цей фахівець повинен мати знання та досвід у тестуванні ПЗ, вміти створювати тестові конвеєри та вміти кодувати.

Орієнтовний стек, сформований на основі співпраці з такими фахівцями:

  • Інструменти для автоматизації тестування: Selenium WebDriver, WebDriverIO, Cypress, Appium (для мобільного тестування), Postman (для API тестування), JMeter (для тестування навантаження).
  • Інструменти для керування тестовими кейсами та звітності: TestRail, HP ALM (Application Lifecycle Management), Zephyr, Xray (для Jira), QTest.
  • Фреймворки для автоматизованого тестування: pytest (для Python), JUnit (для Java), TestNG (для Java), Cucumber (для BDD), Robot Framework.
  • Інструменти для контролю версій та спільної роботи: Git, GitHub, GitLab, Bitbucket.
  • Інтеграція тестування у CI/CD процеси: Jenkins, GitLab CI/CD, Travis CI, CircleCI.
  • Хмарні тестові оточення: AWS Device Farm, BrowserStack, Sauce Labs, TestProject.
  • Контейнеризація тестових середовищ: Docker, Kubernetes (для оркестрування тестових середовищ).
  • Управління конфігурацією тестових оточень: Ansible, Puppet, Chef.
  • Системи моніторингу та відстеження помилок: ELK Stack (Elasticsearch, Logstash, Kibana)Є, Splunk, New Relic, Sentry.
  • Інструменти для створення тестових даних: Faker (для створення реалістичних даних), Mockaroo, Apache JMeter (для створення тестових сценаріїв із реальними даними).
  • Інструменти для тестування безпеки: OWASP ZAP (для автоматизованого тестування безпеки вебдодатків), Burp Suite, Nessus, Qualys.
  • Інструменти для тестування продуктивності: JMeter, Gatling, Locust.

DevOps Automation Expert відповідає за створення автоматизованих конвеєрів CI/CD. Він повинен вміти автоматизувати завдання за допомогою сценаріїв оболонки та мати досвід роботи з інструментами контейнеризації.

Ось орієнтовний стек, сформований на основі власного досвіду:

  • Інфраструктура як код (IaC): Terraform, AWS CloudFormation, Azure Resource Manager (ARM) Templates, Google Cloud Deployment Manager.
  • Контейнеризація та оркестрування: Docker, Kubernetes, Docker Swarm, Amazon Elastic Kubernetes Service (EKS), Azure, Kubernetes Service (AKS), Google Kubernetes Engine (GKE).
  • Системи керування конфігураціями: Ansible, Puppet, Chef, Continuous.
  • CI/CD: Jenkins, GitLab CI/CD, Travis CI, CircleCI, AWS CodePipeline, Azure DevOps Pipelines.
  • Системи моніторингу та логування: Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, New Relic, Datadog.
  • Системи управління версіями коду та спільної роботи: Git, GitHub, GitLab, Bitbucket.
  • Автоматизація тестування: Selenium WebDriver, Postman, JMeter, Robot Framework, Cypress.
  • Управління контейнерами та образами: Docker Registry, Harbor, Amazon ECR (Elastic Container Registry), Azure Container Registry, Google Container Registry.
  • Системи управління секретами та ключами: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault.
  • Мережеві технології: Virtual Private Clouds (VPC), AWS Direct Connect, Azure Virtual Network Google Cloud Virtual Private Cloud (VPC).
  • Інструменти для моніторингу безпеки та сканування вразливостей: Nessus, Qualys, OpenVAS, Clair.
  • Інструменти для аналізу коду та статичного аналізу безпеки: SonarQube, Checkmarx, Veracode.

DevOps Release Manager контролює життєвий цикл доставки програмного забезпечення. Має розумітися на наскрізній розробці ПЗ та життєвому циклі його розгортання. Також він повинен бути комунікабельним, бо йому часто доведеться спілкуватися не тільки з розробниками, а й з замовниками та керівниками проєктів.

Орієнтовний стек, сформований на основі співпраці з такими фахівцями:

  • Системи керування версіями: Git (GitHub, GitLab, Bitbucket), SVN (Apache Subversion).
  • Інструменти автоматизації CI/CD: Jenkins, GitLab CI/CD, CircleCI, Travis CI, TeamCity.
  • Контейнеризація: Docker, Kubernetes (для оркестрування контейнерів).
  • Інфраструктура як код: Terraform, AWS CloudFormation, Azure Resource Manager.
  • Моніторинг та логування: Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana), Splunk.
  • Конфігураційне управління: Ansible, Puppet, Chef.
  • Інструменти співпраці та комунікації: Slack, Microsoft Teams, Jira, Confluence.
  • Інструменти для тестування: Selenium, JUnit, TestNG, Postman.
  • Інструменти безпеки: OWASP ZAP (для тестування вразливостей), SonarQube (для аналізу коду на вразливості), Vault (для керування секретами та ключами).
  • Інтеграція інструментів і моніторинг процесу: Grafana (для візуалізації метрик), Jenkins (для збору статистики CI/CD), Slack або інші інструменти сповіщень (для нотифікацій про статуси релізів).
  • Хмарні платформи: AWS (Amazon Web Services), Azure (Microsoft Azure), Google Cloud Platform (GCP).

Site Reliability Engineer відповідає за стабільність та безперервну роботу ПЗ. У його обов’язки входить підвищення надійності системи, налаштування моніторингів та реагування на появу інцидентів.

Ось орієнтовний стек, сформований на основі власного досвіду:

  • Моніторинг та логування: Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, New Relic.
  • Контейнеризація: Docker, Kubernetes (для оркестрування контейнерів), Istio (для керування мікросервісами).
  • Інфраструктура як код: Terraform, AWS CloudFormation, Azure Resource Manager.
  • Інструменти автоматизації CI/CD: Jenkins, GitLab CI/CD, CircleCI, Spinnaker.
  • Інструменти безпеки: HashiCorp Vault (для керування секретами та ключами), AWS IAM (Identity and Access Management), Azure Active Directory (AD), Kubernetes RBAC (Role-Based Access Control).
  • Моніторинг застосунків: AppDynamics, Datadog, Dynatrace.
  • Інструменти тестування: Selenium, JUnit, TestNG, Postman.
  • Інструменти автоматизації і деплойменту: Ansible, Puppet, Chef.
  • Контейнеризація та оркестрування: Docker, Kubernetes, Helm.
  • Системи керування версіями: Git (GitHub, GitLab, Bitbucket), SVN (Apache Subversion).
  • Хмарні платформи: AWS (Amazon Web Services), Azure (Microsoft Azure), Google Cloud Platform (GCP).
  • Інтеграція інструментів і моніторинг процесу: Grafana (для візуалізації метрик), Prometheus (для моніторингу метрик), Slack або інші інструменти сповіщень (для нотифікацій про статуси системи).

Висновок

У своїй роботі DevOps-інженери охоплюють весь цикл розробки продукту, сприяють співпраці та підвищують ефективність усіх команд розробників.

Вони допомагають розв’язувати проблеми з програмним забезпеченням та автоматизувати рутинні завдання, щоб розробники зосередились на основних аспектах своєї роботи та могли більш плідно працювати над створенням продукту.

Системні адміністратори виконують більш специфічну роботу — підтримують IT-інфраструктуру компанії. На відміну від команди DevOps, вони не втручаються в роботу розробників і допомагають їм не безпосередньо, а опосередковано через підтримку роботу всього необхідного обладнання на піку продуктивності.

Хоча робота в DevOps зазвичай є складнішою, потребує більше знань і навичок, змінити свою роботу системного адміністратора на DevOps-інженера можливо, але лише з належною підготовкою та навчанням.

Якщо у вас виникли питання, ви можете писати у коментарях або ж поставити їх мені на безкоштовному вебінарі про професію DevOps-інженера!

👍ПодобаєтьсяСподобалось23
До обраногоВ обраному11
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Системний адміністратор — не DevOps-інженер.

Тоді девопс інженера швидше qa automation

На мій погляд, стаття не тримається купи. У висновку автор згадує:

У своїй роботі DevOps-інженери охоплюють весь цикл розробки продукту, сприяють співпраці та підвищують ефективність усіх команд розробників.

Та разом з тим, жодна з перерахованих на старті вакансій не містить цього. Це саме вакансії інфраструктурних інженерів на різіні стеки з різним рівнем технічної підготовки.

Я згоден, що потрібно розділяти позиції DevOps Інженера та Системного Адміністратора. Але робити це розділення, наводячи в обовʼязках 4 спільні пункти — хибний шлях. Як і подаючи розмежування за стеком технологій, бо немає жодної проблеми, щоб розкачаний Системний Адміністратор оперував хмарним GKE кластером чи підпилював CI. Що справді варто наголошувати, що DevOps Інженера повинні відрізняти:
— сильні комунікаційні навички і здатність налагоджувати та лідити завдяки ним міжкомандні процеси
— здатність (не вміння робити це якісно, а здатність) писати складніший ніж короткі сценарії код
— бізнесорієнтованість, бо весь концепт DevOps побудований довкола ідеї пришвидшення бізнес процесів повʼязаних з розробкою через використання комунікаційних та інженерних засобів

Направду, мене дуже тішить, що зʼявляються вакансії сильних інфраструктурних інженерів з відповідною зарплатнею, які не підписані модним DevOps. Бо наймаючи DevOps інженера, я очікую перерахованого вище, але на співбесіді частіше отримую хай технічно прокачаних, але Системних Адміністраторів. Вони не хочуть вникати в продуктовий код за потреби, уникають спілкування з командою і оббудовуються лініями захисту, аби лиш тільки їх рідше чіпали. І це окей: вони мають сильні технічні навички в домені, вони їх реалізовують, живуть найкраще життя. Не окей те, що вони позиціонують себе як DevOps Інженера і мені доводиться витрачати більше часу на просіювання кандидатів.

Гадаю, ця проблема повʼязана з тим, що роками домінуючий на ринку OutSource сегмент наймав цих людей на позиції DevOps Інженерів, аби дорожче продавати клієнтам. І зараз ми в ситуації, коли ринок сформований більшою мірою такими спеціалістами.

І хоч я не згоден з позицією та аргументами автора в статті, вважаю важливим, що ми починаємо про це відкрито говорити. Бо лиш так ми зможемо трішки утрясти ринок і спростити життя як кандидатам, так і компаніям, що наймають.

З розділу «Які технології використовують сисадміни та DevOps-інженери» зник шматок тексту. Більша частина технологій, які вказані для сисадмина, насправді для DevOps. При цьому технології для DevOps не вказані взагалі.

Бо вони всі використовують девопс практика
Навіть РМ

І тільки одна посада уа автоматищаьор пайпланів має назву близьку до девопс

Development Support Engineer Tier-4 не вистачає

имхо обычно такие вакансии пишут чтоб сэкономить. типа возьмём сисадмина с претензией на девопса, авось справится. платить будем по рейту сисадмина.) это как тут в комментах упомянули, навешивание на сисадмина функций дба, особенно если бд хозяйство разнородное, немалое и тем более нагруженое — это игра с огнём.)) с другой стороны вот эти наборы инструментов которые вы перечислили актуальными для разных категорий девопсов — оно всё не рокетсаенс. но в тех проектах где глубина понимания, уровень экспертизы и файнтюнинг роляет и может (очень) дорого стоить — да, без команды не обойтись.
ps: сам когда-то в давних нулевых учился дб премудростям на проде, будучи са.. всё рассказать это поэма будет, но именно тогда впервые понял, что человек способен очень, очень быстро учиться когда пришёл пзц.))

DevOps System Engineer
Бази даних та сховища даних: MySQL, PostgreSQL, MongoDB, Redis.

Пурга.
Как бывший DBA, со своей колокольни могу ответить следующее.
Мне не доводилось встречать системного инженера разбирающегося в СУБД.
В лучшем случае что он умеет это:
— просетапить СУБД «как-то»
— на любую проблему с затыком с СУБД реагирует ее рестартом.
— просетапить общепринятую для этой СУБД процедуру бэкапа.
Задавать ему вопросы о распределении памяти или о том почему СУБД под нагрузкой уходит в swap просто бессмысленно.
Как правило, просетапленная процедура бэкапа либо не верифицирована, либо он вам внятно не может ответить, сколько данных будет потеряно в результате восстановления СУБД из бэкапа, и насколько существующие бэкапы функциональны(восстановимы)

Просто многие конторы занимаются очковтирательством, и не хотят брать в штат DBA, пока не случится что-то более или менее серьезное.
У системного инженера много иных вопросов требующих внимания, так что поддержка СУБД обычно находится в конце его списка.

Как правило, просетапленная процедура бэкапа либо не верифицирована, либо он вам внятно не может ответить, сколько данных будет потеряно в результате восстановления СУБД из бэкапа, и насколько существующие бэкапы функциональны(восстановимы)

Та ну нафіг.
Що то за процедура бекапу така, що з неї і не пробували відновитись десь на тестовому сервері?
Це ж зашквар 😁

То что у вы делаете бэкапы не значит, что с них можно сделать рековери.
То что в самом начале вы сделали успешный рековери не значит, что в последствии у этой процедуры не может быть проблем, поэтому для ее верификации необходимо делать регулярную тестовую валидацию
(один из вопросов аудита — показать журнал проверки тестовых валидаций восстановимости бэкапов)
Валидацию можно не делать, если у вас скажем регулярно для нужд тестировщиков выполняется пересоздание тестового env-а из бэкапа prod CУБД ( обычно такое делать нерекомендуется если в СУБД есть sensitive data).

Далее.
В общем случае чтобы восстановить СУБД «до последней транзакции», нужно иметь в наличии
— бэкап файлов данных
— бэкап системного лога с момента бэкап файлов данных.
— целый системный лог.
( в данном случае речь идет о row-based CУБД)

Если системный лог потерян( частое событие), то возможен только частичный рековери, то есть у нас уже есть потери(пусть и небольшие и возможно даже некритичные), и всегда нужно иметь ответ на вопрос «Сколько же мы потеряли», чтобы знать какие действия следует выполнить по процедуре «post-recovery» СУБД.

Далее бэкап может быть логическим и физическим.
Физический — создание физических копий файлов СУБД.
Логический — просто дамп данных из таблицы или СУБД в файлик.
Последний если выполняется на работающей СУБД не гарантирует вообще ничего
ни консистентности данных, ни восстановимости данных на определенный момент времени, если только вы не переводите СУБД в read-only на время бэкапа, поэтому малопригоден в качестве средства для полноценного бэкапа.

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

А еще есть очень непростая тема апгрейдов СУБД. :)

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

+500
Якби я був ДБА у реально серйозної БД, то я б перевіряв рекавері мінімум раз на тиждень, а може і частіше.
Коли працював ДБА з не дуже критичною БД, то робив тестові відновлення раз на місяць, ну і мав ще один сервер, на якому «якщо щось» можна було розгорнути останній Бекап та переключити користувачів на нього.
Звичайно, що з великій конторі таке нереально зробити.

На щастя це ніколи не знадобилось, але мати відпрацьований механізм кращк, ніж не мати 🤣

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

це непрактично і взагалі кажучи не дуже очікувано бізнесом, рестор з бекапу і рекавері з транзакційних логів після цього бекапу на великих базах займе чимало часу, який може коштувати у корпо сотни кіло за годину (це тільки прямі підрахунки зарплатні людей які «замерзли» на той час, непрямі кошти — окремий аспект)

тому ставлять просто другу копію в сінхрон репліку і третю в асінхрон (іноді з затримкою наприклад на 1 годину) і в разі катастрофи перемикають на ноду яка вижила

ну а бекапи теж роблять і тестять звісно, але то вже наступна лінія захисту

працює вся ця схема далеко від ідеального але така практика на ентрепайзах

коли дізастер таки трапляється, дібіей навіть тренований і з усією документацією один х не з пів-тику з ним справляєця, вся ця херня досить складна в реальному житті (коли тих баз десятки-сотні, серверів тисячі і кругом міліони важливих нюансів, це не кажучи про залежності даних, пресінг бізнесу і тп)

рекавері з транзакційних логів після цього бекапу на великих базах займе чимало часу

Ну я власне тому саме це і підмітив:

Звичайно, що з великій конторі таке нереально зробити.

Мабуть вам зустрічались погані сисадміни)

просетапить СУБД «как-то»

з цим енікей впорається. а от не «Как-то», а з необхідними налштуваннями — це робота адміністратора

на любую проблему с затыком с СУБД реагирует ее рестартом.

а якщо після рестарут знов завтик? Та й так просто перезавантажувати можна, якщо з базою працює десяток користувачів. А якщо їх кілька сотень? вам підтримку розірвуть після першого ж такого «експерименту»

Задавать ему вопросы о распределении памяти

у вас дуже, дуже погані системні інженери

просетапленная процедура бэкапа либо не верифицирована

тоді це не процедура бекапа і вважайте, що системи резервних копій у вас нема.

системного инженера много иных вопросов

яких?поремонтувати стіл, бо він комп’ютерний? СУБД — це ядро зберігання даних в будь якій системі. Не підтримувати СУБД — це як їздити на авто без заміни мастила. Можна, щвичайно, але не далеко і зі 100% фейлом в найближчому майбутньому

у вас дуже, дуже погані системні інженери

О да, и так последние 30лет. :)

просетапить СУБД «как-то»
з цим енікей впорається. а от не «Как-то», а з необхідними налштуваннями — це робота адміністратора

Вы просто далеки от этого. :)
Удачи вам и вашим «аникеям», особенно с кластерными СУБД.

просетапить СУБД «как-то»
з цим енікей впорається. а от не «Как-то», а з необхідними налштуваннями — це робота адміністратора

Він то заінсталить
Але на дефолтних налаштуваннях прод ляже через пару місяців.
Трохи краще ситуація з всякими клауд менедж базами.
Там інжуси всім селом помогатимуть таким васям

дивлячись який прод, 95% не ляже (статистику не збирав, виключно моя думка).
Але в цілому ви праві, СУБД потрібно налаштовувати під конкретні задачі, і не для того, шоб «не лягло», а щоб максимально ефективно використовувати наявні ресурси. Тому твердження попереднього коментатора про те, що всі адміни сетаплять «как-то» трохи дивне.

Мій улюблений кейс
База по дефллту в Ул рекавері без бекапу логу.
Кілька місяців і диск повний
Як

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

В случае DevOps-а просматривается следующий алгоритм действий.
— анализ проблемы и генерация фикса для деплой скриптов.
— тестирование и внесенение изменений в baseline.
— автоматизированная накатка изменений на затронутые хосты.

Те відчуття коли робив це й будучи сісадміном)))

не буде потреби в ручному виконанні більшості рутинних задач

В моєму доствіді жоден адекватний сісадмін не робить нічого руками.

Ну а взагалі то, DevOps це про процеси і підходи, а не про людей. Той — кого називають DevOps engineer, то просто скілований сісадмін, який в додаток до інфраструктури вивчив деякі тулзи для автоматизації. За 20+ років в одному і тому самому болоті, ще до появи такого слова як DevOps у компаній були автоматизації, тести, різні енви тощо і без ефемерного DevOps якось справлялись працюючи у відділі автоматизації, мереж та телекоммунікацій одно українського банку.

Перейти з сісадмінства у девопс — не проблема, зі свого досвіду це відбулось за пару тижнів проблема перейти навпаки. Ну і потрібно додати, що клауд провайдерам потрібно якось притягувати клієнтів, проекти, людей і вони пхають той девопс у маси, як свого часу пітон, хоча мені перл був більше довподоби.

PS ну і на додаток — у Класифікаторі професій, немає ніякого девопса, а от Адміністратор системи є.

PPS дякую вам за статтю і за розвиток цього направлення, бо дійсно — бути просто сісадміном, це отримувати на проекті у рази менше грошей, ніж коли ти девопс.

Вивчити за пару тижнів одночасно клауд, докер, тераформ, ансібл, дженкінс та інши тулзи? Ну нехай вам пощастить:)

AWS у мене зайняло десь місяць, разом з Terraform, доречі для Terraform написано пару книжок англійською які читаються одному диханні за пару вечорів (Terraform_ Up & Running — Yevgeniy Brikman, їх було 2 видання, зараз може більше) і маючи досвід того ж AWS, писати код под його інфру — не проблема. Ansible — це навіть не смішно, писати в декларативній формі навіть мій син у 13 років може, інше питання шаблонізатори, але це вже поглиблене як на мене і в ньому можно розібратись якщо знаєш що потрібно. Jenkins — що саме в ньому складного ? Фрістайл джобу зробити ? Якщо з логікою все ок — то немає нічого складного, ускладнене — це написання пайплайнів і groovy, але ж знову — це все ок, якщо з базовими знаннями немає проблем. Якось на співбесіді мене попросили зробити ТЗ — написати пайплайн складний, я погодився лише тому, що хотів прокачатись, ну за 4 дні розібрався, написав. Так що якщо з освітою, досвідом, логікою все ок — то і з навчанням проблем не буде.

"

AWS у мене зайняло десь місяць

Інші тулзи еще деякий час. За два тижні ніяк не вийшло :)

ну таке з вашого боку, якщо чеплятись до кожного слова — то я і досі вивчаю Амазон, Кубернетес, Докер і т.д і це аж ніяк не 2 тижні, а багато років.... Вивчаючи AWS це базово пару днів за рахунок AWS Sysop Operator за умовою що людина розуміє базові речі для сісадміна — мережі, ДНС, мейлінг, протоколи, фаєрволінг тощо. Спеціально подивився на udemy курси Aws sysop -+ 27 годин відео = 3 дні навчання. Terraform + AWS 15 годин відео = 2 дні навчання, Ansible 8 годин відео = 1 день навчання.
Таким чином можна витягнути себе дуже швидко — було б бажання. Я і без udemy перескочив на DevOps з мінімальними занннями AWS/Jenkins/Ansible/Python — просто маючи досвід керування фізичною інфрасткрутурою, деплоєм в ту інфру і коли готувався до сертифікації AWS — то мені було дуже нудно і дивно слухати про Route53 — що таке ДНС, як воно працює, по яких портах, протоколах, те саме про VPC з раутінгом.... тощо. Авжеж якщо бекграунду немає — то ані 2 тижні — ані місяць не вистачить, ані пів року...

В дженкінз може бути складно писати фрагменти коду для всяких дурних плагінів
А на початковому рівні там дійсно лінійео

Що саме AWS?
До рівня початківця щоб почати експериментувати?
Ну так

Щоб індуітивно про це говорити і продавати рішення — сумніваюся

Що саме AWS?
щоб почати працювати

До рівня початківця щоб почати експериментувати?

та і не тільки

Щоб індуітивно про це говорити і продавати рішення — сумніваюся

ну я багато років працюю з AWS, але я не готовий говорити про big data/data lake etc, бо я з цим не працюю — хоча колись і вивчав для себе, отже все дуже залежить від цілей і потреб першого проекту куди націлився. Такий як у мене шлях — не у мене одного, в моєму отоенні достатньо людей хто перейшов у ефемерний девопс з сісадмінства поставивши ціль і не витрачаючи багато часу ознайомившись з основними тулами почав рухатись.

клауд, докер, тераформ, ансібл, дженкінс та інши тулзи

в одного підрядника на проекті був дівупс (теж до речі казав всім що Senior), який з цього переліку вмів тільки в докер і дженкінс
і то досить умовно, бо самостійно запустити дженкінс за кілька днів він так і не зміг, довелось залучати сисадміна
а, ще він Git використовував — заливав туди браузером для зберігання offsite бекап коду проекту у вигляді архівного файлу

Так

Ну а взагалі то, DevOps це про процеси і підходи, а не про людей.
Той — кого називають DevOps engineer, то просто скілований сісадмін

Ще гірше це автоматищаьор якому дозволили деплойипайплайни ддяиапівтпиляти.

І може придбати на тераформ , залежно від структури тіми.
Але назви вже посади

SRE, Cloud engineer, infra eng etc

Майже вийшло
Пропустив продакт овнера
І dbre aka DBA + DevOps
Він теж частина команди що практикує девопс

Гарна стаття, дякую

Дуже цікавий матеріал, здається що все вивчити — анріал задача. Скільки років потрібно на те, щоб стати SRE чи DevOps Release Manager?
І які карʼєрні перспективи у цих сферах? Чи складно знайти роботу? І з чого взагалі стартувати?

Базу для працевлаштування можна освоїти за півроку. Ось репозиторій, який я виклав для всіх бажаючих — github.com/...​ua/wordpress-cloud-at-k8s
Ідіть по комітах і освоюйте :)

Також із стартувати — можна оце www.cloudskillsboost.google/paths/11 . Безкоштовно — зараз іде потік від гугл rsvp.withgoogle.com/...​r-with-google-cloud/about

До появи терміну DevOps Engineer всіма цими задачами займалися якраз сісадміни.
Просто для зручності усіх сторін в індустрії стали виокремлювати цей пул задач в інший тайтл.
Всі говорять, що такої професії не існує, але у вакансіях вказують, здебільшого, саме цей термін, бо на це є суспільна згода і всім це зрозуміло.

Сисадмини пайплайни писали, інфраструктуру в коді створювали, CI/CD займалися? Рілі? :)

Ну можно сказать айтишник и на вебдизайнера и на дба. Сисадмин это не тот кто кабеля сует вам под стол.

Ну були задачі, наприклад ось десяток серверів, ось проект і треба організувати high load та high availability. І організовували деплой, балансировку, бекапи, реплікацію, моніторинг та алерти. Все не так модно та сучасно як зараз, без кубера але багато bash-скриптів, іноді пайтона. RPS’ів не як зараз, але ж 15 років тому і залізо та юзерів було меньше.

Всі сісадміни хто цим займались 10-15 років тому, столи девопсами ізі

Судячи зі списку завдань, ви робили чужу роботу, будучи адміном

Так раніше не було навіть назв таких — devops, infrustructure-інженер, sre, але до 2010 треба ж було проекти запускати/розгортати.

інфраструктуру в коді створювали

сисадміни подібним займались ще задовго до появи як поточних інструментів у вигляді terraform, ansible, etc, так і до виникнення взагалі самого терміну IaC,
використовували шелл-скрипти в *nix, MS RIS, механізми unattended installation, DHCP/BOOTP/PXE, ...
до процесу in-house розробки, так — зазвичай не долучали, тому відсутність в команді розробки людини, яка б розумілась на інфраструктурі рано чи піздно приводила до небажаних ситуацій

Жаль зарплату тоже вынесли с тайтлом.

Так це ж не посада.
Онтгляньте сертифікацію амазон.

Майже всі роли повинні розуміти девопс

Підписатись на коментарі